Can we please parse strings?

As in, without having to write it to a temporary file and then include that
file?

The syntax would be straightforward:

#parse( <text string or string id> )

Post a reply to this message

Chambers <bdc### [at] yahoocom> wrote:
> Can we please parse strings?

  With the current parser the answer is basically no. Too difficult to
implement.

  With a redesigned-from-scratch SDL and parser it should be rather trivial
(although byte-compiling and JIT-compiling could present their own quirks,
but other languages such as PHP manage to do it, so it's definitely possible).

> The syntax would be straightforward:

> #parse( <text string or string id> )

  Functions in the current SDL don't start with a #.

-- 
                                                          - Warp

Post a reply to this message

>> Can we please parse strings?
>
>  With the current parser the answer is basically no. Too difficult to
> implement.
>
>  With a redesigned-from-scratch SDL and parser it should be rather trivial
> (although byte-compiling and JIT-compiling could present their own quirks,
> but other languages such as PHP manage to do it, so it's definitely 
> possible).
>
>> The syntax would be straightforward:
>
>> #parse( <text string or string id> )
>
>  Functions in the current SDL don't start with a #.

Yeah, IMO it'd be OK to continue suporting the "#command parameter"
syntax for 4.0 scripting control structures. A #parse command probably
wouldn't have parens, just quote delimited strings, string identifiers, or
functions returning a string (like concat).

Post a reply to this message

Tim Attwood <tim### [at] comcastnet> wrote:
> Yeah, IMO it'd be OK to continue suporting the "#command parameter"
> syntax for 4.0 scripting control structures. A #parse command probably
> wouldn't have parens, just quote delimited strings, string identifiers, or
> functions returning a string (like concat).

  The main problem with parsing a string as SDL is not a syntactical one,
but related to implementation, especially if and when the new SDL will be
byte/JIT-compiled.

  There's a reason why eg. C++ and Java don't support parsing strings and
interpreting them as C++ or Java. Even many interpreted scripting languages
don't have any parse function because it may not be quite trivial to
implement in them. The current SDL is a good example of this.

  I don't know too much about scripting language interpreters and compilers,
but I can easily imagine a string parsing function being a nightmare to
implement properly. For example, a string could define a new function which
must then be callable from outside the string. This means that you are
creating new functions on the fly, during execution and can't create the
interpreter/compiler so that it just creates a static set of functions.
The string might define new types which should then be usable from the
outside, so the interpreter/compiler must somehow dynamically create
information about new types during runtime, as they are created. This
can easily make the interpreter/compiler much more complex than it would
otherwise be.

  Of course it also means that the byte-compiler and the bytecode interpreter
cannot be independent and separated, but must be married together, as the
bytecode interpreter may need to call the byte-compiler. This effecively
makes it impossible to make a virtual machine which only interprets bytecode,
without a compiler.

  Of course I'm not saying this is impossible. As far as I know, for example
PHP byte-compiles the program before interpreting it, *and* it also has an
eval() function, which effectively parses a given string as PHP code. So it's
definitely possible. Just not trivial.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Chambers <bdc### [at] yahoocom> wrote:
> > Can we please parse strings?
>
>   With the current parser the answer is basically no. Too difficult to
> implement.

It's a good thing that we're not discussing the current parser, then :)

Anyway, my request isn't based on how easy or hard it would be to implement,
but rather on how useful it would be to me.  In the past year, I've run
across more and more situations where I would want this.

Post a reply to this message

Chambers <bdc### [at] yahoocom> wrote:
> Anyway, my request isn't based on how easy or hard it would be to implement,
> but rather on how useful it would be to me.  In the past year, I've run
> across more and more situations where I would want this.

  It would certainly be a handy feature, but will most probably make the
interpreter/compiler more complicated than without it...

-- 
                                                          - Warp

Post a reply to this message

> Warp <war### [at] tagpovrayorg> wrote:
>> Chambers <bdc### [at] yahoocom> wrote:
>>> Can we please parse strings?
>>   With the current parser the answer is basically no. Too difficult to
>> implement.
> 
> It's a good thing that we're not discussing the current parser, then :)
> 
> Anyway, my request isn't based on how easy or hard it would be to implement,
> but rather on how useful it would be to me.  In the past year, I've run
> across more and more situations where I would want this.
> 
> 

Name some. Maybe we don't need an eval()-like function, what we need is 
other features so that we never ever need to use eval.

Post a reply to this message

>   There's a reason why eg. C++ and Java don't support parsing strings and
> interpreting them as C++ or Java. Even many interpreted scripting languages
> don't have any parse function because it may not be quite trivial to
> implement in them. The current SDL is a good example of this.

The main problem with the current method of using an include file is speed.
If it could be done using a virtual file stored in RAM, there could be
a huge gain in speed without fundamentally changing the method.

(Is my memory weakening, or do I correctly remember that, at some point,
  there was a patch, MegaPOV or another, which actually allowed to parse
  a string ?)

Fabien.

Post a reply to this message

Nicolas Alvarez wrote:

>> Anyway, my request isn't based on how easy or hard it would be to 
>> implement,
>> but rather on how useful it would be to me.  In the past year, I've run
>> across more and more situations where I would want this.
>>
>>
> 
> Name some. Maybe we don't need an eval()-like function, what we need is 
> other features so that we never ever need to use eval.

In my case I was using POV-Ray as a graphing calculator and wanted the 
resultant image to show both the text and graphic form of the function. 
   I wanted to only have to enter a function in SDL once, so I used a 
string, and figured out the include-file-method as a workaround to 
convert that string to something plot-able.  I asked on the newsgroups 
if there was a better way... wishing.
Charles

Post a reply to this message

> Nicolas Alvarez wrote:
>>
>> Name some. Maybe we don't need an eval()-like function, what we need 
>> is other features so that we never ever need to use eval.
> 
> In my case I was using POV-Ray as a graphing calculator and wanted the 
> resultant image to show both the text and graphic form of the function. 
>   I wanted to only have to enter a function in SDL once, so I used a 
> string, and figured out the include-file-method as a workaround to 
> convert that string to something plot-able.  I asked on the newsgroups 
> if there was a better way... wishing.
> Charles


#declare F = function { x*2 };
#declare Ftext = f.toString(); // <-- that's probably the feature you need

Or a way to convert a string to a function; note that's still not an 
eval(), as it would be limited to only mathematical expressions.

Post a reply to this message