 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
While 3.7 is still in beta stage, I think it is worth already starting to think
about the next generation SDL, which I guess will be the key feature of POV
4.0.
Yes, a lot has been said about this before, but I propose doing some more
systematic brainstorming.
Yes, it will be up to the POV dev team to decide on how the next generation SDL
will be like; however, they may ultimately decide to pick up a proposal drafted
by the POV community, if there is such a thing and it makes sense.
First, to keep discussion focused, I think it is prudent to distinguish between
various aspects:
- Basic paradigms: What very fundamental properties do we want? (For instance,
the question whether to use a conventional OO- or a functional approach would
fit in here, or whether the language)
- Features: What individual features do we want? (For instance, the question
whether to support Garble-Greeble-Jabberwock-trees would fit in here)
- Syntax: How do we want the features to be accessed? (For instance, the
question how to specify vectors would fit in here)
- Implementation: How can the desired features be implemented "under the hood"?
I guess syntax issues are probably not worth paying too much attention to yet,
as they may be significantly dependent on the basic paradigms or the features
to support - except when talking about basic paradigms of the syntax, so to
speak. Likewise, implementation issues may play a role in discussing the
benefits or drawbacks of other aspects, but I guess most POV users will not
give a damn how the thing works inside, provided it does so sufficiently fast.
So first thing to concentrate on is the basic paradigms and features, before
getting lost in syntax and implementation details.
So, here are a few of my thoughts:
BASIC PARADIGMS
* Multithreading Support
POV is going multithreaded. An SDL that allows to multithread parts or maybe
even all of the parsing would be of benefit there. This might be particularly
of importance for animations.
To flesh out a bit what I'm thinking about here, for instance include files
might be parsed in parallel, unless sequential parsing is explicitly requested
somehow; loops might be marked by the scene developer as fit for parallel
processing (I don't think we want to wait for an SDL implementation that can
automatically identify parallelizable loops); the SDL file may be comprised of
blocks with some hierarchy denoting parts that are independent of each other,
and can therefore be parsed in parallel.
To go a bit into implementation, too (contrary to my own recommendation, but
this one is quite independent of other conceptual issues): The parser could be
split into multiple layers; the lower layer would run in a single thread, but
just read in the scene file and include files, tokenize them, and build a
syntax tree from the tokens; the actual execution of the syntax tree could then
be delegated to a host of threads, using it to generate the geometry for the
engine to render. This would also allow a speed advantage for animations, as
the tokenization step would have to be performed just once.
* Object Orientation
I guess when talking about "the" basic paradigm on which to build the language,
we can't really get around OO these days. We obviously want an approach that is
state-of-the-art, but it also needs to be well enough understood to be both
implemented in reasonable time and efficiently usable for the average POVer, so
that leaves us with only OO or a functional approach for all I can see. And all
in all, I guess OO is much more commonly known among the POV community (and POV
developers, for that matter) than functional programming. I bet every advocate
of the functional approach will know a good deal about OO as well, but hardly
vice versa.
However, I think the most important aspect of OO for POV users would be
encapsulation of data & code, while polymorphism may play a minor role, and
inheritance may be quite well done without - provided that the language
natively supports a good set of generic data containers.
As a matter of fact, I guess a prototype-based (aka class-less) approach at
polymorphism and inheritance, like in JavaScript, would do just fine for POV
needs: While making automatic type checking impossible, I guess that's not a
major concern for the size of common POV "projects". The benefit would be a
very low "formalism profile", ultimate polymorphism, and an inheritance-like
mechanism for free.
I also think it is well acceptable for POV to maintain a conceptual distinction
between built-in types (scene entities like objects, textures, etc., but also
natively supported data containers) and user-defined objects.
As a matter of fact, a very easy way to approach this would be to mimick
user-defined entities via a built-in associative array type (aka dictionary aka
map), and just providing a specialized syntax for accessing such arrays (plus
some optimization based on the expectation that the same keys will typically be
used in many entities).
* Full-Fledged Scripting Language
On the paper, the current SDL is just a static scene description language,
extended with a preprocessor language to allow for some limited scripting
capabilities. Personally, I think this distinction is obsolete, and the new SDL
concept should acknowledge that, down to its very core.
* DOM Access
As of now, SDL can only "write" properties of the entities it describes. Some
have pondered the idea of making them readable, too, and I guess although one
can possibly go quite well without, this is a nice idea.
Similarly, users would probably expect properties to be not only writable, but
modifiable as well. Again, I'd consider this a nice idea.
* Integrated
It has been proposed to just provide an API for POV, and have each user choose
the language they prefer most. However, this would make the POV package
incomplete: You couldn't do anything with it without installing another
software (plus going through the hassle of getting your language of choice to
properly interface to the API).
Thus, even if an API would be added to allow for the use of arbitrary languages,
POV should come with its own integrated standard SDL, so you can still just
install it and get going.
FEATURES
* Namespaces
It seems like all major programming languages have acknowledged the benefit of
giving public identifiers from separate modules separate spaces to "live in",
in order to avoid name clashes.
* Container Data Structures
I think a next generation SDL will need more data containers than just arrays,
like:
- dynamic arrays
- associative arrays (aka dictionaries aka maps, kind of like arrays with
non-numeric indices)
- lists (just a bunch of entities that can be iterated over)
- ordered lists (like lists, but with a defined order for iteration; these may
also allow for access by positional index, like an array, but the mapping will
change whenever elements are inserted or removed)
- sets (lists without duplicates)
In addition, some data structure for spatial lookup may be of particular value,
like an octree or kd-tree.
* Data Tuples
Often I'd love to have a function return not only one value, but a pair of them
or even more (e.g. a point and an associated normal vector). The SDL should
provide for a mechanism to handle such cases easily.
* For Loops
Loops like #local i = 0; #while (i < n) ... #local i = i + 1; #end are
commonplace, and they work, but they suck. I want something like a #for i = 0
to n-1 ... #end.
* Foreach Loops
Iterating over all elements of a data container is commonplace, so there should
be an easy syntax for it, something like #foreach myElement in myArray ...
#end.
For data structures mapping keys to elements, the syntax should also allow for
retrieving the key along with the element, like #foreach (myKey,myElement) in
myMap ... #end; iterating over the keys only should be possible, too, like
#foreach (myKey,) in myMap ... #end, but a syntax to retrieve a list of keys
from the data container would do the same job, like #foreach myKey in
myMap.keys ... #end
* Integer values
I'm always worried when doing things with floats that I would normally use
integers for. I confess that it's probably more of a psychological thing, but
still I want integers.
* Vector and Color functions
Being unable to use vectors within functions sucks.
* Consistent functionality in functions
Being unable to use certain built-in identifiers in functions sucks, too.
SYNTAX
* Basically "C Style"
Although it's probably far too early to talk about individual aspects of syntax,
the overall "look & feel" might already make sense to discuss, or at least
gather ideas about.
I think that with so many "C Style" languages out there and enjoying a lot of
popularity (C, C++, C#, Java, JavaScript to name just the "major players" that
spring to my mind), it doesn't hurt to go for a similar style, both in overall
"look & feel" as well as various details. Not to mention that the curly braces
will maintain some feeling of familiarity :) (It seems like POV's current SDL
was inspired to some degree by C, too.) Another benefit is that POV itself is
written in C++, so the developers themselves are familiar with the style.
Personally, I'd consider only Perl- and Basic-inspired languages to be
widespread enough to use them as a basis for a new POV SDL; however, Perl is
currently undergoing significant syntax changes itself, and Basic will not gain
many supporters in the POV community I guess - let alone having no similarity
whatsoever with the current SDL syntax.
Well, there would be another option: XML. But I don't think we need to discuss
this here: XML is not particularly pretty to work with directly.
* Consistent
The current SDL is a heap of inconsistency regarding when to place a comma, when
to place a semicolon, where parentheses are used and where not (see e.g. #fopen
vs. #write), and so forth. There should be an easy, consistent style regarding
this.
* Clear distinction of types
The distinction between colors and vectors in the current SDL is to some degree
still a mystery to me; I think the two concepts should be better separated.
Similarly, I think a clear distinction between floats and vectors would be good.
Hum, well... I guess that should suffice for now...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote in message
news:web.49cbb9e38a87b99f93bfb07f0@news.povray.org...
> While 3.7 is still in beta stage, I think it is worth already starting to
> think
> about the next generation SDL, which I guess will be the key feature of
> POV
> 4.0.
>
> Yes, a lot has been said about this before, but I propose doing some more
> systematic brainstorming.
A couple of things that I didn't yet see discussed that I think are going to
need to be added into this discussion at some stage:
Backwards Compatibility
There's a lot of time been invested in tutorials, interfaces, macros and
objects.
Much of the written information out on the Internet (including the years of
newsgroup postings) doesn't specify which version it relates to, so if this
material is rendered largely redundant it's probably going to be wise to
totally change the product name. Otherwise there's a risk of years of
confusion that may create difficult barriers to new users.
Inventing New Languages
There are a lot of mature languages about in common usage with comprehensive
and well designed structures and support channels. It may be better to adopt
one existing language, providing API/DOM access to the C++ core with
official support for that language. Enthusiast for other languages could
then add support for other languages as trends change.
Maybe a solution would be to create an integration layer with native support
for an enhanced version of the established POV-Ray SDL and, at the same time
expose the API/DOM. As a particular programming language becomes a popular
choice for the POV-Ray community in years to come it could become the
defacto standard and could be added to the short list of officially
supported languages.
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have written about this years ago already, but here's a quick
recapitulation of what I think would be good for the new scripting
language (and perhaps a few new ideas):
- It must be easily byte-compilable. Preferably to a byte code which may
be easily JIT-compiled to native machine code in some future version.
Even without JIT-compiling just the fact of having it in bytecode
format can make parsing an order of magnitude faster.
- The bytecode will also allow saving scenes in bytecode format for
faster parsing. (Basically the need to parse the scene is removed
completely, except for some sanity checks of the bytecode.)
- Currently there's a distinction between parse-time scripting (the SDL)
and rendertime scripting (user-defined functions, used eg. in isosurfaces).
Rather obviously no such distinction should be made in the new language.
Anything you write should be runnable at parse time and at rendertime
(and also at the post-processing stage).
- Object properties, such as textures, should be fully specifiable using
the scripting language itself (facilitated by the previous point). In
other words, you should be able to write, for example, "shaders" with
the scripting language. This "shader" is evaluated every time that
certain property of the object (eg. its texture) is needed.
This would allow eg. writing an AOI patter with the scripting language,
completely removing the need to add such a pattern to the core renderer.
- Most core renderer features should be available to the scripting language.
As an example, you should be able to launch a ray from a given point and
retrieve the color it returns.
This will allow, among many many things, writing eg. a "portal" shader,
ie. a texture which shows the image as seen by a secondary "camera"
somewhere else. I believe megapov has currently such an option. Rather
than being a core feature, it would be easily implementable with scripting.
- Related to that, the scripting language should be so flexible that many
current core features can be removed from the core renderer and put into
libraries.
Currently there are tons of features in the core renderer which are there
for the sole reason that you can't implement them with the SDL, and there
wouldn't be any other reason for them to them to be there (eg. efficiency).
The core renderer should be as minimal as possible, and only contain
things which have to be there because of efficiency (it would be way too
slow to try to implement them in scripting). The smaller the core renderer
is, the lesser bugs it will have.
(Another advantage is that bugs in libraries are much easier to fix
than bux in the core renderer. Also libraries can be modified by the
user much more easily. Modifying the core renderer is way more laborious
and error-prone.)
Related to that last point, an interesting question is how to provide
standard data containers ? la STL. By the previous principle they should
be provided as libraries. This makes them more flexible, easier to modify,
and removes clutter from the core renderer.
However, there's also a negative side: The STL in modern C++ compilers
is very stable, very well tested and almost certainly bug-free, while
creating equivalents with the new scripting language, no matter how
flexible it might be, is very laborious and will inevitable be ridden
with bugs for years to come. Providing a "wrapper" to the STL in the
scripting as a core feature could be way less work and less error-prone
than trying to re-implement them from scratch using the scripting language.
They will probably also be faster that way (because the container functions
will be compiled, rather than bytecode-interpreted).
If the scripting language is designed smartly enough, it will actually
not make any difference whether the containers are implemented as libraries
written in the scripting language itself, or whether they are a core
feature (acting as STL wrappers). This allows changing the implementation
of any of them from one approach to the other without breaking any existing
scenes. This is a goal to aim for.
- The design principle of the new scripting language should have some kind
of "unified object model" approach. With this I mean that core objects
and user-created objects should work and be usable in the exact same way.
That is, it doesn't matter whether a "sphere" object is a core feature
or something which came from a library. In either case you would use that
"sphere" object in the exact same way (as long as you know its interface,
of course).
For example, if you wanted to access (read, change) the texture of the
object, it would be done with an identical syntax regardless of whether
the object is a core feature or defined in a library.
In object-oriented terms, they would have a common base class (even if
the scripting language wouldn't really use literal inheritance) and you
can handle any object in the same way.
And by "object" I don't necessarily mean literally object primitives
(spheres, boxes), but basically anything povray features (lights, cameras,
textures, arrays...). In other words, regardless of what it is, it should
be usable in the same way regardless of whether it's a core feature or
defined in a library. Of course different types of objects will have
different interfaces (in OO terms, they will have different base classes),
and you have to know the "type" of object you have in order to use it
(eg. handling a sphere is different from handling a texture, for instace,
as they have different type of data), but the point is that the user
doesn't have to know if it's a core feature or a library object in order
to use it (he only has to know its interface).
- As for memory management: Garbage collection (as in the one in Java or C#)
might be nice, but VERY hard to implement efficiently. If possible the
scripting language should be designed in a way which makes creating a GC
engine unnecessary.
This might mean that the only way to use dynamic memory is through the
dynamic data containers provided. However, that might be enough for
almost everything. (After all, most people have done cool things with
the current array feature, even though it's *really* rigid. The new
data containers will be much more flexible.)
- The scripting language should also be designed so that it's easy to
flexibly read, parse and write data files (as well as handle the data
itself). This would allow writing things like 3DS or OBJ file format
importers as libraries. (This is an example of something which should
definitely be a library rather than a core feature.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris B wrote:
> Backwards Compatibility
> There's a lot of time been invested in tutorials, interfaces, macros and
> objects.
> Much of the written information out on the Internet (including the years
> of newsgroup postings) doesn't specify which version it relates to, so
> if this material is rendered largely redundant it's probably going to be
> wise to totally change the product name. Otherwise there's a risk of
> years of confusion that may create difficult barriers to new users.
I doubt a product name change is necessary. However, it should be made
clear all over the place (docs, Web site, etc) that the latest Pov will
break compatibility with anything before v4.
I personally don't think there's a great need to maintain backward
compatibility as far as syntax/code goes. I think the hope is that the
new SDL will provide "nicer"/"better" ways to do stuff than the old SDL
- and so we wouldn't want people being hampered by tutorials from the
past - but force them to learn the new way of thinking.
One possibility is to try to find lots of good tutorials, put them onto
the Wiki (if permission can be acquired), and before POV4 is released,
update the tutorials to show how to get each effect using POV4.
--
A man attempting to walk around the world DROWNED today...
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawaz org<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> - It must be easily byte-compilable. Preferably to a byte code which may
> be easily JIT-compiled to native machine code in some future version.
> Even without JIT-compiling just the fact of having it in bytecode
> format can make parsing an order of magnitude faster.
>
> - The bytecode will also allow saving scenes in bytecode format for
> faster parsing. (Basically the need to parse the scene is removed
> completely, except for some sanity checks of the bytecode.)
I guess this boils down to about the same as what I had in mind about separating
what would basically be the tokenizer, and the actual parser. Except that what
you call bytecode, I'd call a serialized "syntax tree"
I don't think, however, that JIT-compiling would make any sense or be an option:
- A JIT-compiler integrated into POV-Ray itself is, quite obviously, no more
than a distant dream.
- Using an external JIT-compiler would require another piece of software (namely
the JIT-compiler) to run POV; I don't think this is acceptable.
- Integration of an external JIT-compiler would pose major architectural
problems, which I guess are better left unaddressed, given the number of other
ideas pending implementation and the desire of users to have them all ASAP.
> - Currently there's a distinction between parse-time scripting (the SDL)
> and rendertime scripting (user-defined functions, used eg. in isosurfaces).
> Rather obviously no such distinction should be made in the new language.
> Anything you write should be runnable at parse time and at rendertime
> (and also at the post-processing stage).
Yes and no. Obviously the render-time scripting should have exactly the same
syntax as the parse-time scripting, most notably access to the same integrated
identifiers. However, things like generating additional geometric objects, or
even just modifying existing ones, is a definite no-go for render-time code.
Or, to put it in other words: Render-time code should be restricted to read-only
ops. Temp variables would come in handy, but their lifetime and scope should be
limited to the current invocation of the function for a whole bunch of reasons
- the most important being that many POV internals rely on user functions to be
stateless. Throwing this overboard would open up a can of really nasty worms.
> - Object properties, such as textures, should be fully specifiable using
> the scripting language itself (facilitated by the previous point). In
> other words, you should be able to write, for example, "shaders" with
> the scripting language. This "shader" is evaluated every time that
> certain property of the object (eg. its texture) is needed.
....
> - Most core renderer features should be available to the scripting language.
> As an example, you should be able to launch a ray from a given point and
> retrieve the color it returns.
I think these ideas are not realistic in near future, as they require yet
another major architectural change of POV-Ray, and I guess we want a new SDL
earlier. However, it is a good point to keep in mind when designing that
language.
But note also that these shaders, being render-time code, would not be able to
use data caches or stuff alike, due to restriction on statelessness. I'd
advocate that shaders that require stateful operation be written as binary
plug-ins of sort.
> - Related to that, the scripting language should be so flexible that many
> current core features can be removed from the core renderer and put into
> libraries.
Given how complex the render engine currently is regarding even seemingly simple
tasks, such as shooting a ray and seeing what color you get, I must conclude
that (a) heading for that goal would definitely be of benefit for the internal
architecture of the render engine, but (b) I'd be prepared for that goal to be
never actually reached.
In addition, I'd advocate not to implement those functions in script code, but
instead have them remain binary modules, albeit separated from the main engine
code more strictly, e.g. as a kind of plug-in.
> - The design principle of the new scripting language should have some kind
> of "unified object model" approach. With this I mean that core objects
> and user-created objects should work and be usable in the exact same way.
> That is, it doesn't matter whether a "sphere" object is a core feature
> or something which came from a library. In either case you would use that
> "sphere" object in the exact same way (as long as you know its interface,
> of course).
This would presume that the SDL in fact provide an interface to define new
geometric entities. These would have to be render-time code.
I don't really think there is much use for such objects, and that instead giving
more flexibility to functions to be used in isosurfaces is the way to go.
> For example, if you wanted to access (read, change) the texture of the
> object, it would be done with an identical syntax regardless of whether
> the object is a core feature or defined in a library.
Yes, that's an important consistency thing. It will probably also make the
parser more lightweight. At the moment, every property for every thing has its
own code snippet in the parser.
> - As for memory management: Garbage collection (as in the one in Java or C#)
> might be nice, but VERY hard to implement efficiently. If possible the
> scripting language should be designed in a way which makes creating a GC
> engine unnecessary.
> This might mean that the only way to use dynamic memory is through the
> dynamic data containers provided. However, that might be enough for
> almost everything. (After all, most people have done cool things with
> the current array feature, even though it's *really* rigid. The new
> data containers will be much more flexible.)
Yes, I guess this is the way to go. It makes for clear memory handling
responsibilities: The built-in containers do all that's needed; they'll also
care for either copying items, or keeping a reference counter to know when a
shared entity is no longer needed. That should do for most practical purposes
(after all, we're not writing complex business applications in the order of
magnitude of several man-years ;))
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <nom### [at] nomailcom> wrote:
> Backwards Compatibility
> There's a lot of time been invested in tutorials, interfaces, macros and
> objects.
> Much of the written information out on the Internet (including the years of
> newsgroup postings) doesn't specify which version it relates to, so if this
> material is rendered largely redundant it's probably going to be wise to
> totally change the product name. Otherwise there's a risk of years of
> confusion that may create difficult barriers to new users.
There is some point to this; however, that's why it would be "POV-Ray 4.0", and
not "POV-Ray 3.8".
I don't know anything about POV-Ray 2.0, but I bet tutorials on it would be far
from usable nowadays, too.
Backward compatibility could also be maintained by designing the new language
such that it will be compatible to POV 3.x SDL up to (and including) the
"#version" statement, at which point a legacy parser may kick in.
> Inventing New Languages
> There are a lot of mature languages about in common usage with comprehensive
> and well designed structures and support channels. It may be better to adopt
> one existing language, providing API/DOM access to the C++ core with
> official support for that language. Enthusiast for other languages could
> then add support for other languages as trends change.
This would (a) generate a major problem with POV being unusable stand-alone, (b)
require a major effort to implement a whole mature language (and all its
features, because that's what people would expect), or (c) open up the can of
worms called GPL by integrating an existing language interpreter into the POV
package.
> Maybe a solution would be to create an integration layer with native support
> for an enhanced version of the established POV-Ray SDL and, at the same time
> expose the API/DOM. As a particular programming language becomes a popular
> choice for the POV-Ray community in years to come it could become the
> defacto standard and could be added to the short list of officially
> supported languages.
In my opinion the problem with the current SDL is not only that it is showing
its age regarding the features it offers, but also the syntax: It is far from
consistent with itself (just look at #fopen vs. #fwrite: Why does one have the
parentheses, while the other has not?), and needs an overhaul even in that
respect.
I think a redesigned language would actually be of benefit for new users, as it
will be much easier to learn.
If the basic syntax is sufficiently different, but the scene stuff parameter
names are not changed, I guess there will not be much confusion: It will just
be an (obviously) different syntax to access the same properties.
Those tutorials not dealing with scene stuff properties but instead elaborating
on how to work around the shortcomings of the current SDL will be rendered
obsolete anyway by a next generation SDL, or we'd better not talk about a new
SDL at all.
Re established general-purpose language, note also that Perl is currently
undergoing a major syntax overhaul, so even going for established languages
does not save you from incompatibilities between language versions.
Plus, I'd expect API/DOM access from an established language to usually be a
good deal more cumbersome. So instead of writing something like this:
for(i = 0; i < n; i ++) {
sphere (<0,i*2,0>, 1) {
texture {
...
}
}
}
you would for instance need to write something like this:
for(int i = 0; i < n; i ++) {
Sphere mySphere = new sphere(new Vector3d(0,i*2,0), 1);
mySphere.texture = new Texture(
...
);
pov.addToScene(mySphere);
}
So, as a scene designer, which would you prefer?
POV scene description is a highly specialized application, and therefore IMO
advocates a special language. Even if it's only for the native support of 3D
vectors and colors: They're just too commonplace to use general-purpose
languages' typically comparatively cumbersome ways of expressing custom-type
"literals".
Instead, the SDL can fairly well go without various other common features of
all-purpose languages, like event handling, exception handling, inheritance,
sophisticated regular expressions, dynamic memory handling (provided the basic
data containers are good enough), reflection (except maybe some rudimentary
stuff), template classes, interface declarations, and a good deal more, that
really make those languages complicated to implement.
To summarize: No, I don't think it would be prudent to continue extending the
existing SDL after POV 3.9999.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> I guess this boils down to about the same as what I had in mind about separating
> what would basically be the tokenizer, and the actual parser. Except that what
> you call bytecode, I'd call a serialized "syntax tree"
I don't think it's necessary to keep any kind of "syntax tree" data in
any form once the scene file has been parsed and compiled into bytecode.
The bytecode can be very straightforward asm-like series of opcodes and
their parameters. The advantage of this is that it's very fast to interpret
(which can be important at rendertime), and even JIT-compile.
> I don't think, however, that JIT-compiling would make any sense or be an option:
I don't see why not. Many scripting languages have that.
> > - Currently there's a distinction between parse-time scripting (the SDL)
> > and rendertime scripting (user-defined functions, used eg. in isosurfaces).
> > Rather obviously no such distinction should be made in the new language.
> > Anything you write should be runnable at parse time and at rendertime
> > (and also at the post-processing stage).
> Yes and no. Obviously the render-time scripting should have exactly the same
> syntax as the parse-time scripting, most notably access to the same integrated
> identifiers. However, things like generating additional geometric objects, or
> even just modifying existing ones, is a definite no-go for render-time code.
Not "same syntax". The one and only scripting language, down to the bytecode
compiler and bytecode interpreter.
There may be additional limitations for the rendertime code, but
that doesn't mean it has to be separate from the compile-time code.
It makes no sense to create two scripting languages with two compilers
and two interpreters. That will only be more work and very confusing for
the users (even more than the current SDL / user-defined function
distinction).
> > - Object properties, such as textures, should be fully specifiable using
> > the scripting language itself (facilitated by the previous point). In
> > other words, you should be able to write, for example, "shaders" with
> > the scripting language. This "shader" is evaluated every time that
> > certain property of the object (eg. its texture) is needed.
> ....
> > - Most core renderer features should be available to the scripting language.
> > As an example, you should be able to launch a ray from a given point and
> > retrieve the color it returns.
> I think these ideas are not realistic in near future, as they require yet
> another major architectural change of POV-Ray, and I guess we want a new SDL
> earlier.
POV-Ray 4 was supposed to be a complete rewrite anyways. If it is, then
it should be done properly.
> In addition, I'd advocate not to implement those functions in script code, but
> instead have them remain binary modules, albeit separated from the main engine
> code more strictly, e.g. as a kind of plug-in.
That sounds to me like it will only make the whole system more complicated,
not simpler.
A simple core engine (only things which require speed should be there),
a simple script interpreter. Everything else as libraries written in the
scripting language. Let the complexities be inside the libraries, not in
the core engine.
> This would presume that the SDL in fact provide an interface to define new
> geometric entities. These would have to be render-time code.
> I don't really think there is much use for such objects, and that instead giving
> more flexibility to functions to be used in isosurfaces is the way to go.
I consider those sentences contradictory.
"There's no use for user-defined objects. Instead, we should enhance
the properties of usef-defined objects (isosurfaces)."
I'd say no: Don't clutter the already cluttered features with even more
clutter. Instead, make a clean simple implementation which can be used for
the same thing, but with more flexibility.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> > I don't think, however, that JIT-compiling would make any sense or be an option:
>
> I don't see why not. Many scripting languages have that.
Damn it, Jim, POV is a raytracer, not a general-purpose IDE - and our human
resources are limited.
> POV-Ray 4 was supposed to be a complete rewrite anyways. If it is, then
> it should be done properly.
If the intention is to do a *complete* rewrite, then why waste time on a 3.7,
which already is a major architectural overhaul?
> A simple core engine (only things which require speed should be there),
> a simple script interpreter. Everything else as libraries written in the
> scripting language. Let the complexities be inside the libraries, not in
> the core engine.
No, Sir. We're talking about an application that is performance-hungry anyway,
so there should be a way to implement certain things in binary code, yet
separate from the core engine to keep that simple. Otherwise, we will sooner or
later end up with stuff that *does* need speed, and gets hacked into the core
just because there's no clearly defined way to interface binary stuff to it
properly.
Rather do it the other way round: Provide an interface for binary add-ons, then
implement the script language as such an add-on.
Scripting most parts of the software is ok when performance is not paramount,
like e.g. a web browser: You want it to be fast, but more importantly you want
it to be safe, comfortable etc., and you probably can't tell the difference
whether a page takes 0.5 or 0.6 seconds to load. You can tell the difference,
however, whether an animation takes 5 or 6 days to render.
>
> > This would presume that the SDL in fact provide an interface to define new
> > geometric entities. These would have to be render-time code.
>
> > I don't really think there is much use for such objects, and that instead giving
> > more flexibility to functions to be used in isosurfaces is the way to go.
>
> I consider those sentences contradictory.
>
> "There's no use for user-defined objects. Instead, we should enhance
> the properties of usef-defined objects (isosurfaces)."
Isosurfaces provide a simple, single-function interface to define objects.
Internally in POV, however, the interface is much different, and consists of
multiple methods: One to compute ray-object intersections, one to perform an
inside test, one to compute the surface normal for a given point, and so forth.
So when I hear "user-defined objects", I think of exposing *that* interface.
To me, isosurfaces are just that: Isosurfaces. A hard-coded shape that just
happens to be very flexibly parameterizable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> * For Loops
>
> Loops like #local i = 0; #while (i < n) ... #local i = i + 1; #end are
> commonplace, and they work, but they suck. I want something like a #for i = 0
> to n-1 ... #end.
>
I hope I'm not weighing in with some 'simpleton' comments here (I'm definitely
NO computer scientist), but the way I approach discussions of a proposed new
SDL language is strictly from the standpoint of 'comfortable usability.' As
basically a non-programmer (except with the SDL), I would want to see a
language that made 'simple sense' as to its syntax. For example: The #while
loop is easily understood, simply from the fact of its name. Using #for instead
seems a bit 'obtuse' as to its meaning (except among programmers, of course!)
But that's the point: If the new language is to have 'non-programmer'
adherents, then its syntax should be 'obvious' as to what it does, and easily
understood. (Of course, there are plenty of current SDL terms that probably
don't fall into that category, yet we've all learned to use them.) I guess my
basic concern is not to alienate new users (or even old ones) with new syntax
that seems strange, or rather, non-obvious as to its meaning.
Of course, I could be the 'odd-man-out'; perhaps the majority of POV-Ray users
*do* actually come from some kind of programming background, where 'odd' syntax
terms are of no consequence.
Ken W.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kenneth <kdw### [at] earthlinknet> wrote:
> The #while loop is easily understood, simply from the fact of its name.
I beg to differ. I once wrote a long page dedicated solely to explaining
how the #while loop does and doesn't work, because misunderstandings are
so common:
http://tag.povray.org/povQandT/whileloops.html
For many non-programmers it's not at all obvious how they work, which
is the reason why mistakes are common, and often a source of obscure errors
for which questions get posted to the newsgroups. Especially nested loops
tend to cause confusion. For a programmer and for people who have used the
while loops it's simple, but for someone who has never used them it might
not be.
A simple for-loop removes most if not all the confusion.
And it's not like the for-loop would *replace* while-loops.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> A simple for-loop removes most if not all the confusion.
I'm not sure. The opinions of people like Kenneth are quite valuable here,
because they are still at a place that those of us who write code fluently can
only dimly remember. I honestly can't remember if I had more trouble with for
loops than while loops when I was learning to program. From where I'm standing,
it could easily be argued that for loops are the more challenging.
> And it's not like the for-loop would *replace* while-loops.
Well, true. If we have both, then it's not an issue :-)
As an aside, I think there *has* to be a legacy parser (as I believe clipka
suggested). There is just too much useful stuff that will break, and users who
will either stick to pre-4.0 versions or stop using POV completely. Also,
having a simpler, more 'approachable' SDL will encourage users in, as it does
now. I see no problem in the old-style option being more restrictive; this
will, in turn, encourage the more confident user to move on to the new. Of
course, we will need plenty of code and tutorials posting here in the early
days to help everyone out!
(Don't get me wrong, I'm all in favour of a new SDL - indeed, I'm salivating at
the possibilities!)
Bill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
> > The #while loop is easily understood, simply from the fact of its name.
>
> I beg to differ. I once wrote a long page dedicated solely to explaining
> how the #while loop does and doesn't work, because misunderstandings are
> so common:
>
> http://tag.povray.org/povQandT/whileloops.html
My main concern is actually with 'semantics' (if that's the right word.) I.e.,
the term #while seems to be quite logical and understandable in its meaning:
"while (this is true) do this stuff" etc. Same thing with #if. But--using #for
as an example again--I'm not so sure I understand what "for" signifies, in an
English syntax sense. (Actually, I do seem to recall 'for-next' being a part of
Fortran IV that I learned long ago in college. I think. Which has been my only
experience with 'real' computer programming, aside from Basic or one of its
iterations on an old Commodore computer. But #for doesn't immediately create a
mental picture of what it does.) So my own desire would be to have SDL syntax
that is as easy (or even easier) to 'quickly grasp' than the current version's.
KW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bill Pragnell <bil### [at] hotmailcom> wrote:
> As an aside, I think there *has* to be a legacy parser (as I believe clipka
> suggested). There is just too much useful stuff that will break, and users who
> will either stick to pre-4.0 versions or stop using POV completely.
It's reasonable to expect that some kind of legacy parser module will
be possible, which will allow rendering old scenes with POV-Ray 4.0 (what
the parser internally would do is to convert the old SDL input so that it
can be parsed by the new parser, or such; I'm not sure it would be a great
idea to replicate object creation etc. in two places).
However, if the new scripting language is a complete rehaul, it will not
be possible to call eg. macros of the old SDL from the new scripting
because they will simply be incompatible. Basically it will be impossible
to convert old SDL macros to the new scripting in all possible cases because
macros are not pure functions. With current macros you can create ugly hacks
like opening a { block in your main scene and closing it inside a #macro
(which may be cool for short code contests, but makes things like byte
compiling a nightmare, if not an impossibility).
In fact, any kind of legacy parser and converter (be it internal or a
separate tool) will be a rather large job. I have this little feeling that
this might actually never happen due to lack of labor force. Someone would
have to volunteer to do this, and he would have to do it properly.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> However, if the new scripting language is a complete rehaul, it will not
> be possible to call eg. macros of the old SDL from the new scripting
> because they will simply be incompatible. Basically it will be impossible
> to convert old SDL macros to the new scripting in all possible cases because
> macros are not pure functions.
It might not be feasible to actually call the old macros from within the new
SDL, but surely they could be run by the old parser to generate 'pure'
old-style SDL that could then be converted? That would be perfectly adequate in
most cases, I would think.
> With current macros you can create ugly hacks
Not so much of a loss if these get wiped. No decent macro should rely on such
voodoo! I'm sure there'll be some equivalent hackery we can exploit for bizarre
coding contests...
Bill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
> I hope I'm not weighing in with some 'simpleton' comments here (I'm definitely
> NO computer scientist), but the way I approach discussions of a proposed new
> SDL language is strictly from the standpoint of 'comfortable usability.' As
> basically a non-programmer (except with the SDL), I would want to see a
> language that made 'simple sense' as to its syntax. For example: The #while
> loop is easily understood, simply from the fact of its name. Using #for instead
> seems a bit 'obtuse' as to its meaning (except among programmers, of course!)
Good point - unfortunately, for us programmers the "non-obviousness" of such
things is not obvious for us ;) So we definitely need non-programmers to point
such things out to us.
How about this - would these be more obvious for a non-programmer? (Be invited
to pick your favourite or roll your own)
#for i from 0 to N-1 ... #end
#with i from 0 to N-1 ... #end
#foreach i in 0 to N-1 ... #end
> Of course, I could be the 'odd-man-out'; perhaps the majority of POV-Ray users
> *do* actually come from some kind of programming background, where 'odd' syntax
> terms are of no consequence.
.... which is not necessarily the point, because even if most POV-Ray users would
come from a programming background, it could be *because* the syntax might be
not obvious enough to others. Which in that case would rather speak in favor of
making the language more intuitive to noobs.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
> My main concern is actually with 'semantics' (if that's the right word.) I.e.,
> the term #while seems to be quite logical and understandable in its meaning:
Actually, I remember that when I started programming, I was multiple times
fooled by the while-loop, about when the condition is checked. The most
intuitive loop, for me, was:
REPEAT
...
UNTIL (condition);
which did exactly what I always expected it to do: Execute the list of
statements, *then* check for the condition, and if it didn't hold true, repeat
the whole smash over and over again.
Then again, maybe this is still not the most intuitive, as there might be some
confusion whether the statements are executed if the condition doesn't hold
true right from the start, so maybe this would be the clearest (albeit not the
most elegant):
REPEAT {
...
IF (condition) END REPEAT
...
}
Note that you can build *any* type of loop from this:
// while(condition) ...:
REPEAT {
IF (NOT condition) END REPEAT
...
}
// repeat ... until(condition):
REPEAT {
...
IF (condition) END REPEAT
}
// for i from 1 to n:
LET i = 1
REPEAT {
IF (i > n) END REPEAT
...
}
BTW, as another alternative for the for-loop, how about this:
REPEAT COUNTING i FROM 1 TO n {
...
}
I guess that should be plain enough. Otherwise I give up ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> As an aside, I think there *has* to be a legacy parser (as I believe clipka
> suggested). There is just too much useful stuff that will break, and users who
> will either stick to pre-4.0 versions or stop using POV completely.
Actually, I'm currently pondering the possibility of what would be a more
formalized variant of the current SDL, in an attempt to remove its
inconsistencies while making it a rather easy task to port existing code to the
new version.
It would probably be an easy thing to modify the existing SDL parser *now* to
accept both variants of the language for now side by side, throwing a warning
e.g. per file if it finds old syntax, allowing for a rather smooth transition;
if that new syntax was introduced anytime soon *now*, maybe the old style would
be "obsolete enough" to drop support with POV 4 - which would then allow to
downsize the parser a good deal.
I'll post on this idea soon.
Just for starters: The main difference would probably be a significant increase
in the number of semicolons used.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/26/2009 11:37 AM, Chris B wrote:
> wise to totally change the product name. Otherwise there's a risk of
> years of confusion that may create difficult barriers to new users.
ACtually, this probably isn't a bad idea. Perhaps Scene Object
Language, or Scene Programming Language, to distinguish it from the
current SDL.
In fact, if that's the case then the current parser could be kept for
backwards compatability, activated by an appropriate #version directive
(or whatever the equivalent would be in the new language) but remain
static and disallowing access to features exclusive to the new language.
--
...Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> On 3/26/2009 11:37 AM, Chris B wrote:
> > wise to totally change the product name. Otherwise there's a risk of
> > years of confusion that may create difficult barriers to new users.
>
> ACtually, this probably isn't a bad idea. Perhaps Scene Object
> Language, or Scene Programming Language, to distinguish it from the
> current SDL.
Ah, now I get that point...
With the language no longer claiming to be merely a descriptive language for POV
scenes, I think the term "Scene Scripting Language" would be fitting.
(Dibs on the name "POV-Slang", which I intend to use as the name of a particular
proposal for such a language.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> Just for starters: The main difference would probably be a significant increase
> in the number of semicolons used.
I'm not liking the sound of that. I really like being able to eg. create
lists of elements in a loop without having to worry about the commas.
If you make the current SDL "more formalized" and "consistent", you will
be removing a lot of its current flexibility which makes it so great.
(Also being forced to create all the necessary commas in the loop,
except for the last element which is never followed by a comma, will
make the resulting SDL code to be more hackish and might not, in fact,
make it any easier to create any kind of converter from it to a new
language.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> Actually, I remember that when I started programming, I was multiple times
> fooled by the while-loop, about when the condition is checked. The most
> intuitive loop, for me, was:
> REPEAT
> ...
> UNTIL (condition);
> which did exactly what I always expected it to do: Execute the list of
> statements, *then* check for the condition, and if it didn't hold true, repeat
> the whole smash over and over again.
The problem with that is that it will execute the body always at least
once. If it should never be executed (which isn't even a rare occurrence),
you will need to add a conditional around the entire repeat-until loop,
and the condition will be a duplicate of the 'until' condition.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
>
> How about this - would these be more obvious for a non-programmer? (Be invited
> to pick your favourite or roll your own)
>
> #for i from 0 to N-1 ... #end
> #with i from 0 to N-1 ... #end
> #foreach i in 0 to N-1 ... #end
>
>
Cool! I get to choose a keyword for the new SDL. :-P I feel like a contestant
on that U.S. TV game show "The Price Is Right": "Let's see, I think I'll
choose door number...THREE. No, wait...number FOUR!"
Actually, in looking up the definition of a #for loop, I really can't think of
an easy English-syntax equivalent. And I see that #for is a basic keyword of
almost all computer languages--so changing it would be silly, I guess.
> > Of course, I could be the 'odd-man-out'; perhaps the majority of POV-Ray
> > users *do* actually come from some kind of programming background, where
> > 'odd' syntax terms are of no consequence.
>
> .... which is not necessarily the point, because even if most POV-Ray users
> would come from a programming background, it could be *because* the syntax
> might be not obvious enough to others. Which in that case would rather speak
> in favor of making the language more intuitive to noobs.
That's an interesting point, one that I hadn't considered. And I would agree.
(I'm not sure why the SDL learning-curve didn't put ME off when I started with
POV-Ray--probably because the astounding visual results of the program just
outweighed any seeming syntax difficulties. I just *had* to learn it!
Hopefully, that's how other newbies react to the SDL as well. And it goes
without saying that POV-Ray is not for everyone--but then neither are the
plethora of other programming languages out there. You have to be willing to
take a leap into a 'new world.' And as the saying goes, "No pain, no gain.")
KW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> clipka <nomail@nomail> wrote:
> > Just for starters: The main difference would probably be a significant increase
> > in the number of semicolons used.
>
> I'm not liking the sound of that. I really like being able to eg. create
> lists of elements in a loop without having to worry about the commas.
> If you make the current SDL "more formalized" and "consistent", you will
> be removing a lot of its current flexibility which makes it so great.
Warp, please make up your mind: Do you want a *scripting* language, or a
*preprocessing* language?
In a preprocessing language, you indeed have to worry about the commata because
you're generating *source* code that will be parsed again.
In a scripting language, you just loop and add elements to some data container.
I thought you were so much in for render-time scripting with some VM; how on
earth are you going to do that with a preprocessing language??
> (Also being forced to create all the necessary commas in the loop,
> except for the last element which is never followed by a comma, will
> make the resulting SDL code to be more hackish and might not, in fact,
> make it any easier to create any kind of converter from it to a new
> language.)
Now how come you're talking about commata here??
I never mentioned them.
You're over-reacting based on pure assumptions. Please keep calm and wait for
what I'll present before going on a pre-emptive strike against it, okay?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
>
> > REPEAT
> > ...
> > UNTIL (condition);
>
> > which did exactly what I always expected it to do: Execute the list of
> > statements, *then* check for the condition, and if it didn't hold true, repeat
> > the whole smash over and over again.
>
> The problem with that is that it will execute the body always at least
> once. If it should never be executed (which isn't even a rare occurrence),
> you will need to add a conditional around the entire repeat-until loop,
> and the condition will be a duplicate of the 'until' condition.
I didn't claim that to be the ideal loop. I just said it was the most intuitive
in my eyes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
> (I'm not sure why the SDL learning-curve didn't put ME off when I started with
> POV-Ray--probably because the astounding visual results of the program just
> outweighed any seeming syntax difficulties. I just *had* to learn it!
Maybe that's because with POV-Ray, you have always something more you *can*
learn, but not much that you *must* learn. Any you always have plenty of ways
to do things. For example, you can choose whether you prefer to invest lots of
time coding routine stuff, or hack up an awfully complex macro to do it for
you. It's all up to whoever is in charge of the keyboard.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka escreveu:
> Warp <war### [at] tagpovrayorg> wrote:
>> clipka <nomail@nomail> wrote:
>>> Just for starters: The main difference would probably be a significant increase
>>> in the number of semicolons used.
>> I'm not liking the sound of that. I really like being able to eg. create
>> lists of elements in a loop without having to worry about the commas.
>> If you make the current SDL "more formalized" and "consistent", you will
>> be removing a lot of its current flexibility which makes it so great.
>
> Warp, please make up your mind: Do you want a *scripting* language, or a
> *preprocessing* language?
>
> In a preprocessing language, you indeed have to worry about the commata because
> you're generating *source* code that will be parsed again.
If povray was to use Scheme as scripting language, there would be no
such worries:
'(1 2 3 4 5 6 7 8)
Or:
(define vec (make-vector 10))
((range 0 9) '() (lambda (i o) (vector-set! v i (* i i)) o))
v => #(0 1 4 9 16 25 36 49 64 81)
After all, Lisp syntax is very uniform. Besides, there are quite a few
good and small Scheme open-source interpreters out there geared for
scripting.
Of course, while there would be no semicolons, there'd be lots of
parentheses. ;)
and here ends Scheme advocacy. Your turn, Andrew.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> Warp, please make up your mind: Do you want a *scripting* language, or a
> *preprocessing* language?
I want the current SDL to remain as flexible as it is now. There's no
need to make it more rigid just for the sake of it being "easier for
a converter to parse".
Scripting languages should make the life of the users easier, not the
other way around.
> In a preprocessing language, you indeed have to worry about the commata because
> you're generating *source* code that will be parsed again.
> In a scripting language, you just loop and add elements to some data container.
The current SDL has no data containers (except for the very rigid array),
and everything is created as SDL source. Thus it should remain as a
preprocessing language in order to make this task easier.
The new scripting language can use a completely different approach.
> I thought you were so much in for render-time scripting with some VM; how on
> earth are you going to do that with a preprocessing language??
I never wanted a render-time scripting VM for the *current* SDL. That's
just impossible.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> If povray was to use Scheme as scripting language, there would be no
> such worries:
> '(1 2 3 4 5 6 7 8)
>
> Or:
> (define vec (make-vector 10))
> ((range 0 9) '() (lambda (i o) (vector-set! v i (* i i)) o))
>
> v => #(0 1 4 9 16 25 36 49 64 81)
Yuck! No way am I gonna support *that* approach >_<
Not that I'd say Scheme or Lisp would suck, but... well, I don't have the
slightest clue how to *decipher* it - could be ROT13-encrypted ancient egypt,
from all I see :P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> I want the current SDL to remain as flexible as it is now. There's no
> need to make it more rigid just for the sake of it being "easier for
> a converter to parse".
>
> Scripting languages should make the life of the users easier, not the
> other way around.
Yes, and that's *exactly* why a scripting language should be consistent in its
own grammar.
Now tell me, why are the arguments to #write and #read in parentheses (including
the file descriptor), while those of #fopen and #fclose are not?
Why does #debug take a single string, while #write takes an arbitrary mix of
strings, floats or vectors?
Why is the comma between the value and the co-ordinate of a cubic spline point
mandatory, while that between the co-ordinate and the next point isn't?
Why is a semicolon after a #define and #version statement required, but nowhere
else?
Just a few examples.
> The current SDL has no data containers (except for the very rigid array),
> and everything is created as SDL source. Thus it should remain as a
> preprocessing language in order to make this task easier.
Maybe we have a misunderstanding here. When I mentioned my proposal would mainly
add a lot of semicolons, I was talking about existing features. It would provide
quite a few more.
> The new scripting language can use a completely different approach.
>
> > I thought you were so much in for render-time scripting with some VM; how on
> > earth are you going to do that with a preprocessing language??
>
> I never wanted a render-time scripting VM for the *current* SDL. That's
> just impossible.
It is impossible indeed for code relying on the preprocessor nature of the SDL.
But I consider it reasonable to deprecate such code.
Note that I'm not talking about the *current* SDL. I'm talking about a *new* SDL
that will - to the extent that macros are "well-behaved" - have a strong
syntactical resemblance to the current one.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Not that I'd say Scheme or Lisp would suck, but... well, I don't have the
> slightest clue how to *decipher* it - could be ROT13-encrypted ancient egypt,
> from all I see :P
Errata: read v as vec. :P
>> (define vec (make-vector 10))
This is clear enough, I guess: defines vec to be the result of
(make-vector 10), which should be self-evident as well: makes a vector
(array) of 10 elements.
>> ((range 0 9) '() (lambda (i o) (vector-set! vec i (* i i)) o))
This is not plain Scheme, it's an idiom I use. Let's decompose it.
First: in Lisp, anything in the head of a list (everything between
parentheses) should be a function or a macro, should the list be
evaluated. An unevaluated list is like '(1 23 "foo") etc. It's said to
be quoted.
For instance:
(+ 1 2 3) results in the application arguments 1,2,3 to function +, thus
yielding 6
'(+ 1 2 3) results in the list with the symbol + and numbers 1,2,3.
So from now on it's obvious that (range 0 9) results in a function,
otherwise it wouldn't be in the head.
range is a handy function that returns, guess what!, another function.
The function returned is an *iterator* for the given "range", in this
case, 0 to 9.
The *iterator function* so returned gets 2 parameters: the /initial
value/ to be used as first result and a /reducer function/ that takes
the current iteration step and the current result and returns a new result.
So, '() is the /initial value/ and (lambda (i o) (vector-set! vec i (* i
i)) o) is the /reducer function/ I provided. Both are fed to the
*iterator function* returned by (range 0 9) which will successively feed
the /reducer/ the current iteration item and the result so far.
In other words: range returns a "functional" for loop. :) (I don't like
Scheme's standard loop mechanism, "do")
(lambda args body ...) is Scheme's way of creating an anonymous
function. I could as well just previously defined it and given the name
to the iterator, say:
(define powerize (lambda (i o) (vector-set! vec i (* i i)) o))
or sugared:
(define (powerize i o) (vector-set! vec i (* i i)) o)
and then:
((range 0 9) '() powerize)
anyway, (vector-set! vec i (* i i)) sets vector vec element i (vec[i] in
C) to be (* i i). And what is i? i is the first argument to the
/reducer function/, which represents the current iteration item, in this
case a number in the 0-9 range.
Summing up: given i = from range 0 to 9, it will set the current vector
element to i*i.
Let's put c and my scheme idiom side-by-side:
((range 0 9) '() (lambda (i o) (vector-set! vec i (* i i)) o))
for(int i=0;i++<10;)vec[i]=i*i;
whoa! Just remember it's all but a user-defined function with no
syntatic sugar provided by macros wrapping it up. I could just as well
provide one such sugared version:
(define-syntax for
(syntax-rules (=>)
((for i from to => body ...)
((range from to) #t (lambda (i o) (begin body ...) o)))))
(for i 0 9 => (@! vec i (* i i)))
for(int i=0;i++<10;)vec[i]=i*i;
Much better. :)
@! is my personal alias for vector-set!
Also, not seen here is the hability to actually have some useful result.
I mean, setting elements of an array is pretty much an imperative
operation, but still you could simply pass the result of the whole call
to yet another function using the vector just set, simply by doing:
((range 0 9) vec (lambda (i o) (vector-set! vec i (* i i)) o))
and then, using it like:
(vector-ref ((range 0 9) vec (lambda (i o) (vector-set! vec i (* i i))
o)) 2) => 4
Something you can't do with the built-in C for loop.
Was it really that hard? :)
BTW, aside from not mentioning it is a lexically-scoped language, you've
just learned pretty much all the basic semantic of Scheme. It is that
simple a language. Even though my particular idiom may sound a little
daunting at first... :P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] nospam-gmailcom> wrote:
> Errata: read v as vec. :P
Ah, yes, maybe *that's* why I didn't get it?! ;P
> Let's put c and my scheme idiom side-by-side:
>
> ((range 0 9) '() (lambda (i o) (vector-set! vec i (* i i)) o))
> for(int i=0;i++<10;)vec[i]=i*i;
Well, that's (1) not plain C but C++, and (b) obfuscated. Plain, common-style C
would be:
int i; for (i=0;i<10;i++) vec[i]=i*i;
> (for i 0 9 => (@! vec i (* i i)))
>
> Much better. :)
Um... for an obfuscated code contest - yes, I guess so :P
I don't claim the C family of languages to have a less obfuscated syntax - but I
have a feeling that at least the basic concept is much more "digestible" to the
average programmer...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> nemesis <nam### [at] nospam-gmailcom> wrote:
>> Errata: read v as vec. :P
>
> Ah, yes, maybe *that's* why I didn't get it?! ;P
LOL. ok...
> int i; for (i=0;i<10;i++) vec[i]=i*i;
Excellent. Just beat it. ;P
>> (for i 0 9 => (@! vec i (* i i)))
>>
>> Much better. :)
>
> Um... for an obfuscated code contest - yes, I guess so :P
Hmm, I could be more verbose, but then C folks would pick on it not
being concise.
(for i from 0 to 9 => (vector-set! vec i (* i i)))
Nevertheless, don't you find it amazing to be able to simply churn out
new syntax as you see fit?
> I don't claim the C family of languages to have a less obfuscated syntax - but I
> have a feeling that at least the basic concept is much more "digestible" to the
> average programmer...
Frankly, is the above syntax truly hard to figure it out? But yes, C is
digestible simply because of sheer familiarity. It's like Windows.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] nospam-gmailcom> wrote:
> (for i from 0 to 9 => (vector-set! vec i (* i i)))
>
> Nevertheless, don't you find it amazing to be able to simply churn out
> new syntax as you see fit?
#define FROM for(int
#define TO ;!(
#define INCREMENT );
#define BEGIN ++){
#define END }
FROM i = 1 TO i = 10 INCREMENT i
BEGIN
END
didn't test it, but if I'm not mistaken it should be perfectly valid C++ code.
I have one word for that:
Inconsistency.
*You* can read it, but someone else must first learn your brand-new churned-out
syntax to grasp your code.
Yes, great for obfuscating. No, bad for anything that requires teamwork.
> Frankly, is the above syntax truly hard to figure it out?
Yes - not primarily because the syntax is hard to read, but primarily because
I'm not accustomed to this kind of basic approach. The shorthand syntax just
makes things worse by not giving any clue (just like for someone just learning
C, I guess).
> But yes, C is digestible simply because of sheer familiarity.
> It's like Windows.
No, its higher digestibility lies not only in the sheer familiarity of C itself
(and its heirs), but mainly in that the basic *concept* is probably familiar to
*any* programmer. I can't imagine a programmer who has in his whole life never
ever gotten in touch with imperative programming. But I know a whole bunch of
software developers who, confronted with the question what functional
programming languages they know, would probably answer with a puzzled "what?"
So it's not like Windows. It's like GUI. Everyone has seen it, and everyone
knows at least a *bit* of how to get along in it somehow; even if all your
computer experience was from a Mac, you'd have at least some vague idea of how
to do *something* in Windows - and vice versa; even those who prefer to work
with vi typically know at least a bit about how to operate a GUI. - But place a
random person in front of a console with vi running, and they'll be lost.
Utterly. They wouldn't even be able to shut down the computer (well, unless
they have access to the power switch).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> nemesis <nam### [at] nospam-gmailcom> wrote:
>> (for i from 0 to 9 => (vector-set! vec i (* i i)))
>>
>> Nevertheless, don't you find it amazing to be able to simply churn out
>> new syntax as you see fit?
>
> #define FROM for(int
> #define TO ;!(
> #define INCREMENT );
> #define BEGIN ++){
> #define END }
>
> FROM i = 1 TO i = 10 INCREMENT i
> BEGIN
> END
>
> didn't test it, but if I'm not mistaken it should be perfectly valid C++ code.
It's a very cheap and limited preprocessing trick which won't work if
you want to place things differently. In Scheme/Lisp you have true
syntatic abstraction and it's used for very good purposes. Macros are
an intrinsic part of Lisp.
For instance, I can rewrite the same syntax for various purposes:
(define-syntax for
(syntax-rules (=> from to in resulting initially do:)
; simple list iteration
((for i in ls do: body ...)
(for-each (lambda (x) (let ((i x)) body ...)) ls))
; imperative iteration over numeric range
((for i from x to y do: body ...)
((range x y) #t (lambda (i o) (begin body ...) o)))
; functional iteration over numeric range
((for i from x to y resulting j initially init do: body ...)
((range x y) init (lambda (i o) (let ((j o)) body ...))))))
and then use :
> (for x from 1 to 2 do:
(for y from 1 to 3 do: (display x)(display y)(newline)))
11
12
13
21
22
23
true
> (for item in '(1 2 3) do: (display item)(newline))
1
2
3
> (for x from 5 to 1 resulting y initially () do: (cons (* 2 x) y))
`(2 4 6 8 10)
And the real bad deal: your example looks more like pascal than C.
Lisp code is extremely regular, it always look alike, despite new handy
syntax.
Plus, if I want to DECREMENT in your example I'm screwed, most likely
having to resort to a different "begin" to try to get around the fact
that the new "syntax" has its semantics fixed in place but scattered all
around the labels.
> I have one word for that:
>
> Inconsistency.
Indeed.
> *You* can read it, but someone else must first learn your brand-new churned-out
> syntax to grasp your code.
Not a problem in Lisp culture, where people read the code by scope.
> No, its higher digestibility lies not only in the sheer familiarity of
> C itself (and its heirs), but mainly in that the basic *concept* is
> probably familiar to *any* programmer.
Funnily enough, and except for the syntatic abstraction, my example
dealt only with function definition and function application. I thought
those concepts were flying around for ages now.
well, ok, functions returning functions is not generally mainstream...
> So it's not like Windows. It's like GUI. Everyone has seen it, and everyone
> knows at least a *bit* of how to get along in it somehow; even if all your
> computer experience was from a Mac, you'd have at least some vague idea of how
> to do *something* in Windows - and vice versa; even those who prefer to work
> with vi typically know at least a bit about how to operate a GUI. - But place a
> random person in front of a console with vi running, and they'll be lost.
> Utterly. They wouldn't even be able to shut down the computer (well, unless
> they have access to the power switch).
It's an interesting comparison.
Here's a more interesting one: put a novice with no knowledge of
programming languages in front of the monitor and ask him/her what
he/she figures out of this one:
(for x from 1 to 5 do: (display x)(newline))
and then this one:
int i; for(i = 1; i <= 5; i++) printf("%d\n", i);
What is the point of this little experiment? To show that creating your
own syntax clearly has many benefits (specially for DSLs) -- like making
it more suited for the audience/domain or if you simply don't dig the
basic cryptic one -- and that awkwardness is in the eyes of the
beholder. Lisp folks are known to create the language most well suited
and then program in that.
Scheme is often taught in first year compsci courses because of its
simplicity: function definition and function application is all there
really is to it, predefined syntatic details is minimal. So, I feel
astonished when people find it overwhelming.
That said, I wasn't *seriously* proposing Scheme for povray's scripting
language in the first place although I do believe it could be beneficial
in many ways.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> nemesis <nam### [at] nospam-gmailcom> wrote:
> > Errata: read v as vec. :P
>
> Ah, yes, maybe *that's* why I didn't get it?! ;P
>
> > Let's put c and my scheme idiom side-by-side:
> >
> > ((range 0 9) '() (lambda (i o) (vector-set! vec i (* i i)) o))
> > for(int i=0;i++<10;)vec[i]=i*i;
>
> Well, that's (1) not plain C but C++, and (b) obfuscated. Plain, common-style C
> would be:
>
> int i; for (i=0;i<10;i++) vec[i]=i*i;
>
> > (for i 0 9 => (@! vec i (* i i)))
> >
> > Much better. :)
>
> Um... for an obfuscated code contest - yes, I guess so :P
>
> I don't claim the C family of languages to have a less obfuscated syntax - but I
> have a feeling that at least the basic concept is much more "digestible" to the
> average programmer...
If it can be useful the point of view of a non-programmer and a beginner in
POV-ray...
POV language is simple and intuitive, and there are not hateful things, like:
- *<>* or *</>* for each line...
- long word, filled with *__*, etc.
- incomprehensible characters for each line, as: *&*, *$*, *£*, etc...
- billion of brackets of all types that disorientate...
Here, would it be possible to make the POV-language more powerful while
preserving the characteristics of simplicity?
:-)
--
Carlo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> > for(int i=0;i++<10;)vec[i]=i*i;
> Well, that's (1) not plain C but C++
That has been valid C for 10 years now.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chambers" <ben### [at] pacificwebguycom> wrote in message
news:49cd21cc$1@news.povray.org...
>
> In fact, if that's the case then the current parser could be kept for
> backwards compatability, activated by an appropriate #version directive
> (or whatever the equivalent would be in the new language) but remain
> static and disallowing access to features exclusive to the new language.
>
This would make a lot of sense, at the very least as a transition strategy.
Otherwise the cutover is likely to leave most of the existing community
using the scene files, macros and utilities that they know work with the old
software and a small new community that learns the new software.
Having such a transition would permit teething problems with the new
unproven approach to be ironed out and omissions, where the new software
can't do all that the old software did, to be bridged. It would also allow
time for a reasonable proportion of the assets developed for POV-Ray to be
migrated across. A process that won't really even be able to start in
earnest until V4 is demonstrably stable (unless of course we build 6 years
of Beta testing in the plan :-)).
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mueen Nawaz" <m.n### [at] ieeeorg> wrote in message
news:49cbd590$1@news.povray.org...
> Chris B wrote:
>> Backwards Compatibility
>> There's a lot of time been invested in tutorials, interfaces, macros and
>> objects.
>> Much of the written information out on the Internet (including the years
>> of newsgroup postings) doesn't specify which version it relates to, so
>> if this material is rendered largely redundant it's probably going to be
>> wise to totally change the product name. Otherwise there's a risk of
>> years of confusion that may create difficult barriers to new users.
>
> I doubt a product name change is necessary. However, it should be made
> clear all over the place (docs, Web site, etc) that the latest Pov will
> break compatibility with anything before v4.
When you say "all over the place" you may be able to access a few sites, but
when newbies do a Google and discover thousands of sites containing
materials most of which just inexplicably don't work and can't readily be
made to work then it's likely to have a very negative effect on their
impression of the software.
> I personally don't think there's a great need to maintain backward
> compatibility as far as syntax/code goes. I think the hope is that the
> new SDL will provide "nicer"/"better" ways to do stuff than the old SDL
> - and so we wouldn't want people being hampered by tutorials from the
> past - but force them to learn the new way of thinking.
Well yes. Hope springs eternal :-) But reality depends upon people who hope
that they will show an aptitude for developing a fantastic new computer
language (when they've probably never done that before) realising their
particular dreams in a way that other people can stomach.
> One possibility is to try to find lots of good tutorials, put them onto
> the Wiki (if permission can be acquired), and before POV4 is released,
> update the tutorials to show how to get each effect using POV4.
As one of the few who has added stuff to the Wiki I can testify to how
quickly that sort of thing falls onto the shoulders of a very small number
of people. The amount of such work that can be realistically completed is
invariably tiny compared with initial expectations.
In this case there are some very practical problems with this as it would
require people with a reasonable knowledge of the old SDL and a good
knowledge of how the future SDL would best achieve the same results. Doing
this before the code is finished might require a disproportionately high
number
of genius level experts.
Also, this misses the point a bit in that you can create up-to-date
tutorials
but they'll be competing for prominance in Google with a greater number of
better established, but out of date tutorials that don't contain any
indication
that they may be out of date.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <nom### [at] nomailcom> wrote in message
news:49ce0c87@news.povray.org...
> Well yes. Hope springs eternal :-) But reality depends upon people who
> hope
> that they will show an aptitude for developing a fantastic new computer
> language (when they've probably never done that before) realising their
> particular dreams in a way that other people can stomach.
>
No offense intended :-)
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] nospam-gmailcom> wrote:
> Funnily enough, and except for the syntatic abstraction, my example
> dealt only with function definition and function application. I thought
> those concepts were flying around for ages now.
>
> well, ok, functions returning functions is not generally mainstream...
Nor is functional programming in general.
Sure, Pascal has functions. Basic has functions. In C, the whole program is
comprised of functions, and the methods omnipresent in its heirs like C++ and
Java can be seen as another flavor of the same thing.
But if you look closer at these languages, you will find that those functions
are still both defined and used in an imperative fashion. (And all of these
languages actually have not only functions, but also procedures, that don't
return a value at all but just cause side effects. Even C has "functions" that
return "void", i.e. nothing.) It's only recently that design patterns borrowed
from functional programming are gaining popularity.
> Scheme is often taught in first year compsci courses because of its
> simplicity: function definition and function application is all there
> really is to it, predefined syntatic details is minimal. So, I feel
> astonished when people find it overwhelming.
Maybe it's a bit like Go: The rules are mind-boggingly simple. But winning a
game of Go takes more than knowing the rules.
And first years compsci courses are given to people who have time to dig into
new concepts. Many programmers I know don't come from a compsci background. And
you don't learn functional programming in places where there's work to do. Not
typically, at least.
> That said, I wasn't *seriously* proposing Scheme for povray's scripting
> language in the first place
I never really assumed you were ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Carlo C." <nomail@nomail> wrote:
> If it can be useful the point of view of a non-programmer and a beginner in
> POV-ray...
.... which is well appreciated and actually of high valuable in this context, as
it is virtually *impossible* for any programmer to assess a programming
language's "approachability" (or absense thereof) to beginners.
Maybe it's the most important point of view we need to take into account. After
all, POV-Ray is a raytracer first, and although it is obviously primarily aimed
at people who can get along quite well without a "wysiwyg" type of 3D modelling
tool, and one of its *strenths* is its integrated programming language, still
it aims for a much broader audience than just full-fledged software developers.
> POV language is simple and intuitive, and there are not hateful things, like:
>
> - *<>* or *</>* for each line...
I bet (and hope and pray!) POV's SDL will *not* go XML ;)
> - long word, filled with *__*, etc.
Doesn't remind me of a particular language. But I guess what you're saying is
that a POV language should use short (yet clear) words.
> - incomprehensible characters for each line, as: *&*, *$*, *£*, etc...
Like in that language occasionally referred to as "the duct-tape of the
Internet"? Yeah, with duct tape you can do just about anything quite fast, but
the result always looks ugly, and you better have the job re-visited soon in a
more professional fashion ;) (Well, after all, "perl" is not a "pearl" ;))
(Then again, I'm not perfectly sure whether that is the kind of stuff you are
referring to.)
> - billion of brackets of all types that disorientate...
Yes, the typical POV script has those omnipresent curly braces for nesting
objects and their properties, some parentheses for some mathematical formulae,
and an occasional square bracket for array indices, and that's it, basically.
Which is possibly why I'm still irritated at the square brackets used for maps.
> Here, would it be possible to make the POV-language more powerful while
> preserving the characteristics of simplicity?
You definitely have a point here.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> clipka <nomail@nomail> wrote:
> > > for(int i=0;i++<10;)vec[i]=i*i;
>
> > Well, that's (1) not plain C but C++
>
> That has been valid C for 10 years now.
There are still environments where the original C89 ANSI-C is *the* C standard.
Not only because of compiler availablility.
For instance, high-reliability systems written in C are often required to be
MISRA-C compliant - which as of today still demands use of plain vanilla C90
ANSI-C (if I'm not mistaken; it may be even C89).
The least common denominator today is still C89 ANSI-C (and actually only a
subset thereof, namely that which is not specified as leading to
compiler-specific or undefined behavior).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <nomail@nomail> wrote:
> [-- text/plain, encoding 8bit, charset: iso-8859-1, 21 lines --]
> Warp <war### [at] tagpovrayorg> wrote:
> > clipka <nomail@nomail> wrote:
> > > > for(int i=0;i++<10;)vec[i]=i*i;
> >
> > > Well, that's (1) not plain C but C++
> >
> > That has been valid C for 10 years now.
> There are still environments where the original C89 ANSI-C is *the* C standard.
I don't see how that's relevant in this specific context. It's a bit
like saying "we should support Windows 3.1 because some old computers
might still be using it". May be *technically* true, but in practice
mostly irrelevant in this context.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> > > > > for(int i=0;i++<10;)vec[i]=i*i;
> > >
> > > > Well, that's (1) not plain C but C++
> > >
> > > That has been valid C for 10 years now.
>
> > There are still environments where the original C89 ANSI-C is *the* C standard.
>
> I don't see how that's relevant in this specific context. It's a bit
> like saying "we should support Windows 3.1 because some old computers
> might still be using it". May be *technically* true, but in practice
> mostly irrelevant in this context.
That was also the case for my statement "that's (1) not plain C but C++", and
therefore also for your statement "That has been valid C for 10 years now." As
a matter of fact, this branch of the thread has left "the specific context"
quite a while already ;)
Bottom line: Looks like I have scored a point in this nitpicking contest, by my
opponent - after having jumped in on the game at first - now backing off into
pointing out that I'm nitpicking :P
(Yeah, I love having the last word in an argument, as silly as it may ever be
;))
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris B wrote:
> When you say "all over the place" you may be able to access a few sites,
> but
> when newbies do a Google and discover thousands of sites containing
> materials most of which just inexplicably don't work and can't readily be
> made to work then it's likely to have a very negative effect on their
> impression of the software.
One possibility is to have POV-Ray detect somewhat that the syntax
being used may be the old one, and have it fail with an explicit
explanation so that they can go to the official docs.
Frankly, though, I have difficult imagining that someone who's never
used POV-Ray before wouldn't at least take a glance at the official
docs. There _are_ some great tutorials out there, but I'm not sure I saw
more than a few that are accessible to complete newbies.
> Well yes. Hope springs eternal :-) But reality depends upon people who hope
> that they will show an aptitude for developing a fantastic new computer
> language (when they've probably never done that before) realising their
Well, if they've never coded POV-Ray, then they'll be learning a new
language regardless. And frankly, the current SDL sucks as a language.
I guess your concern is more the people who _do_ know POV-Ray from before.
> Also, this misses the point a bit in that you can create up-to-date
> tutorials
> but they'll be competing for prominance in Google with a greater number of
> better established, but out of date tutorials that don't contain any
> indication
> that they may be out of date.
Actually, I'd suspect the opposite. Not sure how Google page rank
works, but if there are only a few pages out there about POV-Ray 4, then
they'll each get more hits and are more likely to show up on top on Google.
I know your concerns, but I think it's a fallacy _never_ to change the
SDL. Maintaining backward compatibility will always be a limiting factor
in development. It'll be a pain to add drastically new features (such as
a custom shading language), while trying to make those new features
compatible with the old SDL. And has been pointed out elsewhere,
backward compatibility has been broken in the past as well.
--
If you try to fail, and succeed, which have you done?
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
How about also get rid of #declare. Is it really needed. Why not just have
direct assignment without the need of a directive:
// Declare an object but don't create it
ball = sphere
{
...
}
// Create an object
object
{
ball // reference to previously declared object
....
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Allen" <bri### [at] yahoocom> wrote:
> How about also get rid of #declare. Is it really needed. Why not just have
> direct assignment without the need of a directive:
>
> // Declare an object but don't create it
> ball = sphere
> {
> ...
> }
This would require some alternative way of indicating whether the variable is to
have global or inc/macro scope (#declare vs. #local); I guess we wouldn't want
to ditch the #declare but keep the #local.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Another feature I'd suggest for the new SDL: "pattern" being fully
interchangeable with 3-parameter function.
Always having to wrap the one inside the other is cumbersome without need (in my
eyes).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/30/2009 7:41 PM, clipka wrote:
> Another feature I'd suggest for the new SDL: "pattern" being fully
> interchangeable with 3-parameter function.
Why not go one further, and remove one of them?
Everything could be represented as functions of the form
<vB1,...> pattern my_func(<vA1,..>)
That is, everything could be called a pattern, could take a vector with
Na components as an argument, and return a vector with Nb components.
Anywhere you would expect either a pattern or a vector, the new style
pattern could be used.
--
...Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/27/2009 9:52 AM, clipka wrote:
> "Kenneth"<kdw### [at] earthlinknet> wrote:
>> My main concern is actually with 'semantics' (if that's the right word.) I.e.,
>> the term #while seems to be quite logical and understandable in its meaning:
>
> Actually, I remember that when I started programming, I was multiple times
> fooled by the while-loop, about when the condition is checked. The most
> intuitive loop, for me, was:
>
> REPEAT
> ...
> UNTIL (condition);
That's usually represented as
do {
stuff
} while (condition);
--
...Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
