Darren New <dne### [at] sanrrcom> wrote:

> What the current POV calls "parsing" isn't what things like ANTLR do.
> "Parsing" (in the non-POV sense) means building a data structure
> isomorphic to the input source code. "Parsing" in the POV sense includes
> things like executing the while loops, while in the ANTLR sense it does
> not. So with a parser generator, you'd have three phases: parsing
> (fast), evaluating (putting together all the objects in the scene), then
> rendering (calculating pixel colors).

My point above was mainly concerned with how *OTHER* tools can *VALIDATE*
any given SDL code, not with how POV-ray will parse a SDL.
In my example I need a lexer for PovClipse telling me what's wrong with a
given SDL. I do not need to care about how POV-ray will internally
implement the step between the SDL token recognition and building the
internal data structure.
All I need to know is:
* is the SDL valid
* if not, where are the errors (missing braces, semicolons, misspellings...)

In order to archive this the best thing to have is a complete,
programmatically usable sytactical grammar description which you can easily
feed into tools like ANTLR.
And in my opinion the one providing such a grammar description should be the
one implementing it, thus POV-ray.

- Wolf

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:

> My point: unless you change the meaning of "parsing" (which doesn't speed up
> anything, and therefor would be, imho, considered useless), parsing is NOT
> neceseraalery (I hate that word, never get it even close to right, probably
> cause I'm not even trying anymore) 'very quick', on the contrary.

OK, let's clarify things a bit:

This thread is concerned with the part from reading the SDL file to
recognize the SDL tokens within it *ONLY*.
The steps involved between token recognition and building the internal data
structure was never meant to be part of this discussion.
Obviously the time needed for this step(s) depends heavily on the *content*
of the SDL (many loops creating objects...), while the time needed to
recognize the SDL tokens should only be depended on the *length* of the SDL
file.

- Wolf

Post a reply to this message

> Darren New <dne### [at] sanrrcom> wrote:
> 
>> What the current POV calls "parsing" isn't what things like ANTLR do.
>> "Parsing" (in the non-POV sense) means building a data structure
>> isomorphic to the input source code. "Parsing" in the POV sense includes
>> things like executing the while loops, while in the ANTLR sense it does
>> not. So with a parser generator, you'd have three phases: parsing
>> (fast), evaluating (putting together all the objects in the scene), then
>> rendering (calculating pixel colors).
> 
> My point above was mainly concerned with how *OTHER* tools can *VALIDATE*
> any given SDL code, not with how POV-ray will parse a SDL.
> In my example I need a lexer for PovClipse telling me what's wrong with a
> given SDL. I do not need to care about how POV-ray will internally
> implement the step between the SDL token recognition and building the
> internal data structure.
> All I need to know is:
> * is the SDL valid
> * if not, where are the errors (missing braces, semicolons, misspellings...)
> 
> In order to archive this the best thing to have is a complete,
> programmatically usable sytactical grammar description which you can easily
> feed into tools like ANTLR.
> And in my opinion the one providing such a grammar description should be the
> one implementing it, thus POV-ray.
> 
> - Wolf
> 
> 

That's impossible to do with the current SDL syntax. Abusing macros and 
loops you could make the syntax change from valid to invalid depending 
on what frame number you're rendering. And the only way to test that is 
interpreting the whole scene code with the current parameters, which 
could very well take hours on some scenes with built-in physics 
simulations :)

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> That's impossible to do with the current SDL syntax.

True, that's why I was referring to the new 4.0 syntax. For the 3.6 syntax
it *is* impossible to write a grammar usable with ANTLR, see my statements
above.

> Abusing macros and
> loops you could make the syntax change from valid to invalid depending
> on what frame number you're rendering.

Why would there be such a thing like syntactically invalid frame code? If
it's invalid POV-ray can not render it.

> And the only way to test that is
> interpreting the whole scene code with the current parameters, which
> could very well take hours on some scenes with built-in physics
> simulations :)

An option deactivating the automatic syntax validation could solve this as
well as the invalid-frame thing above.


- Wolf

Post a reply to this message

>> Abusing macros and
>> loops you could make the syntax change from valid to invalid depending
>> on what frame number you're rendering.
> 
> Why would there be such a thing like syntactically invalid frame code? If
> it's invalid POV-ray can not render it.
> 

Exactly. And you want PovClipse to notice that before POV-Ray attempts 
(and fails) to render it, right?

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> >> Abusing macros and
> >> loops you could make the syntax change from valid to invalid depending
> >> on what frame number you're rendering.
> >
> > Why would there be such a thing like syntactically invalid frame code? If
> > it's invalid POV-ray can not render it.
> >
>
> Exactly. And you want PovClipse to notice that before POV-Ray attempts
> (and fails) to render it, right?

Yes indeed, that's the intention.
Part of this this feature is already implemented: PovClipse nags about any
word which is not a known POV or MegaPOV keyword, the name of a declared
variable or macro.
The next step would be the **syntactical** errors, but for this I need a
grammar definition to be used with ANTLR or similar tool, and this is what
this thread is all about.

- Wolf

Post a reply to this message