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