|
|
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
|
|