Hi,


Please provide support for lexical scanner generators like ANTLR
(http://www.antlr.org) or Flex (http://flex.sourceforge.net) by providing a
grammar definition for them!

Why is that?

* Example one - PovClipse: PovClipse (http://povclipse.sourceforge.net) is
an Eclipse plugin for SDL file editing. If you use Eclipse for Java
development you probably love the feature that Eclipse marks all your Java
syntax errors and misspellings using a red wiggle mark. The very same
should be true in terms of PovClipse: if the SDL code you write is not


impossible to write a lexer for the 3.6 SDL using a lexer generator due to
the fact that the 3.6 SDL is a grown language. Trust me, I tried really
hard. The only thing I could teach PovClipse is to underline everything
which is not a keyword, a declared variable or macro name.

* Example two: If you want to check whether the SDL code generated by your
tool is valid or not you have to be able to parse it with something else
than POV-Ray.


It would be a real benefit for POV-Ray itself if a complete grammar
definition is used for the SDL parsing. The parsing of the SDL would be a
clean, fast and traceable process, the parser can easly switch between



Bottom line: if the new SDL is a rewrite please consider providing a grammar
definition for a lexical scanner generator like ANTLR or Flex. I personally
would prefer ANTLR 3.0.
If you do a little google research you will find that many peoply have tried

failed due to the fact that there is no programatically useable SDL grammar
definition.

My 2 cents.

- Wolf

Post a reply to this message

Wolf wrote:
> Hi,
> 
> Another topic for the „new SDL“ discussions out there:
> Please provide support for lexical scanner generators like ANTLR
> (http://www.antlr.org) or Flex (http://flex.sourceforge.net) by providing a
> grammar definition for them!

Unfortunately scanner and parser generators are highly inefficient to
maintain when it comes to non-trivial languages. That is why i.e. gcc
nowadays has a hand-written parser implementation.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:

> Unfortunately scanner and parser generators are highly inefficient to
> maintain when it comes to non-trivial languages. That is why i.e. gcc
> nowadays has a hand-written parser implementation.

True, but if the language has a proper design the grammar maintenance is not
that bad.
There are syntax complete ANTLR grammars for all Java versions out there,
and i would consider Java a non-trivial language.

Maintenance has to be done from one version to the next one, and as we all
know POV-ray is not released very often.

Take it as a chance for a clean implementation, not as a annoying thing to
do.

- Wolf

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Wolf wrote:
> > Hi,
> >

> > Please provide support for lexical scanner generators like ANTLR
> > (http://www.antlr.org) or Flex (http://flex.sourceforge.net) by providing a
> > grammar definition for them!
>
> Unfortunately scanner and parser generators are highly inefficient to
> maintain when it comes to non-trivial languages. That is why i.e. gcc
> nowadays has a hand-written parser implementation.
>
>  Thorsten

Right. Perhaps its is a chance for us that the new grammar is intended to be
simple (which does not mean 'limited'). However, if it apears that
ready-made lexical scanner generators are not OK for our purpose, writing a
hand-made one will not be very difficult to specialists. I hope ....

Bruno

Post a reply to this message

"Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote:

> Right. Perhaps its is a chance for us that the new grammar is intended to be
> simple (which does not mean 'limited'). However, if it appears that
> ready-made lexical scanner generators are not OK for our purpose, writing a
> hand-made one will not be very difficult to specialists. I hope ....

Well, if the new SDL has a grammar which is not representable by a
general-purpose lexical scanner generator like ANTLR there should be a
quite good reason to do so. Why would you want to write a complete scanner
generator if you get one for free by using open source products?

You have to implement the parsing rules anyway. If you implement them by
hand you will probably end up producing spaghetti code containing lot of
"IF" statements.
By writing a grammar specification and using a scanner generator you get
much cleaner entry points to parts of the grammar (high-level ones like
textures as well as low-level ones like vectors).


Maybe a hand-written scanner is faster than a generated one, but speed
considerations should not be overweighted here as the parsing time is
negligible  compared to the rendering time.

- Wolf

Post a reply to this message

"Wolf" <nomail@nomail> wrote:
> Maybe a hand-written scanner is faster than a generated one, but speed
> considerations should not be overweighted here as the parsing time is
> negligible  compared to the rendering time.

I find parsing can easily be comparable to the render time for the scenes I
render (use of meshes and medium-complexity macros). I don't really have a
point, except to say that I don't think I'd stick with it if the parsing
got any slower in future versions.

Tom

Post a reply to this message

"Wolf" <nomail@nomail> wrote:
> "Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote:
>
> > Right. Perhaps its is a chance for us that the new grammar is intended to be
> > simple (which does not mean 'limited'). However, if it appears that
> > ready-made lexical scanner generators are not OK for our purpose, writing a
> > hand-made one will not be very difficult to specialists. I hope ....
>
> Well, if the new SDL has a grammar which is not representable by a
> general-purpose lexical scanner generator like ANTLR there should be a
> quite good reason to do so. Why would you want to write a complete scanner
> generator if you get one for free by using open source products?
>
> You have to implement the parsing rules anyway. If you implement them by
> hand you will probably end up producing spaghetti code containing lot of
> "IF" statements.
> By writing a grammar specification and using a scanner generator you get
> much cleaner entry points to parts of the grammar (high-level ones like
> textures as well as low-level ones like vectors).
>
>
> Maybe a hand-written scanner is faster than a generated one, but speed
> considerations should not be overweighted here as the parsing time is
> negligible  compared to the rendering time.
>
> - Wolf

If the new syntax does not break the limitations of lexers, we can use one
of them, of course!

If you express the syntax in BNF form as an LL(1) grammar, you can write
quite easily a syntax-directed parser by applying well known rules between
BNF and the language (control statements) you write the parser in. Without
obtaining spaghetti. Perhaps there are some specialists in programing
languages here who can tell more.

My opinion is that whatever parsing technique is used, performances are not
much of a concern: with the machines we have today it will be ALWAYS very
quick for any scene/module we will ever have to parse. The renderer, on the
other hand, must be highly optimized for massive (and vectorized, because
it's the nature of the problem) computations.

Bruno

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruno Cabasson wrote:
> My opinion is that whatever parsing technique is used, performances are not
> much of a concern: with the machines we have today it will be ALWAYS very
> quick for any scene/module we will ever have to parse.

Some people here will beg to differ with you. :-)

Then again, with the exception of, say, large meshes, strictly *parsing*
a scene probably will always be fairly fast; it's the execution of SDL
loops and macros that gets hairy. However, Povray seems to consider that
as part of the "parsing" process.

FWIW, I've worked on scenes that took 10-15 seconds just to "parse" (due
to loops that procedurally generated lots and lots of objects).

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you hear a name beginning
with the letter K and wonder if it's David Buck's middle name.
    -- Alex McLeod a.k.a. Giant Robot Messiah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBYnMcCmTzQ++ZncRAg2KAJ9gwSuXSegTq3ruAlntHzWEPFVCaQCgoHJr
0WTezCJyu4IzcqzUb/nSE8s=
=nm/j
-----END PGP SIGNATURE-----

Post a reply to this message

Tom York wrote:
> I find parsing can easily be comparable to the render time for the scenes I
> render (use of meshes and medium-complexity macros). 

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

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

> FWIW, I've worked on scenes that took 10-15 seconds just to "parse" (due
> to loops that procedurally generated lots and lots of objects).

that's nothing, I, and I believe I'm not the only one, have worked on scenes 
that took a couple of minutes to parse.
Very irritating sometimes, because a mosaic-preview of the scene often only 
takes a couple of seconds.  So I'll have to wait ten times the tracing-time 
just to notice the camera is facing the wrong direction :)

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.

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message