Warp wrote:
> Jeff Houck <jho### [at] northrimnet> wrote:
>> Personally, I like the SDL just the way it is... Simple, mostly 
>> predictable and easy to use...
> 
>   ... very limited and very slow.
> 
>   Also, from core developement point of view, it's quite horrible.
> For example, why do you think there's no eval() function in POV-Ray?
> That is, a function which takes a string and evaluates this string
> as if it was SDL (similar to how an #include "file" would do, but
> with a string instead)?
>   Answer: Because the parser is a mess, full of kludges, burdened with
> backwards-compatibility. For example, #macros are handy and powerful...
> too powerful for their own good. #macros are one of the major reasons
> why there's no eval() function in POV-Ray.
> 
>   Adding new features to the parser is a real pain sometimes (I have
> recent personal experience), mainly due to how the SDL works and is
> parsed. For example, being able to insert a #declare almost anywhere
> may feel handy, but is a nightmare to parse properly.
>   One thing I recently tried to achieve was string concatenation using
> the + operator (as an alternative to the concat function). In the end
> it seems that this would be really, really difficult to implement in
> the current parser due to how interpreting # commands (which can appear
> almost everywhere) works.
> 

I was unaware that the parser was in such sad shape... I'm more of an 
end-user than developer in this case...

I've been trying to follow both of the SDL threads and one thing has 
occurred to me, why not expose the core interface API to a language like 
Python? It's cross-platform, object oriented and has been used 
successfully as a scripting interface to a number of projects. 
Currently, we're using Python-Ogre to prototype a game framework and the 
implementation works great! Python has a number of programming tools 
available across a number of OS platforms, AND, it's not a hard language 
to learn or master...
Just a thought...

Post a reply to this message