|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nathan Kopp wrote:
> "Daniel Hulme" <pho### [at] isticorg> wrote...
>
>>Someone has just asked me why the POV-Ray parser is written the way it
>>is rather than using a standard lexer-/parser-generator. I was unable to
>>give a useful answer. OOC, does anyone know, or is it just one of those
>>things that made sense at the time for reasons lost in the mists of
>>eternity?
>
>
> There are a few reasons I can imagine:
> 1) Age of the code (probably the primary reason, as parser generators might
> not have been as popular when DKB Trace was originally created)
> 2) Simplicity of the original scene description language (SDL) (i.e. no
> loops, conditions, or variables)
> 3) Very close connection between SDL and renderer
> 4) Many small, compounding changes over time, favoring backwards
> compatibility
> 5) It works; nobody's found a compelling reason to rewrite it
You might add:
6) Modularity, as most part of the SDL is only possible in some
"context" (a finish is only possible in the right block...)
7) Easy extensibility, no need to mangle the whole lex syntax to add a
new kind of block (usually, it's a new object or a new pattern...)
The povray parser works like a XML-SAM parser, they are really a
nightmare to write within a single dispatch loop...
A DOM like parser would be interesting, but would be far more heavier.
(but that's nearly what you ask when asking a lex parser)
Moreover, before jumping on the rewrite, beware of:
- variables identifier
- expressions
they will already make writing the lex source 'interesting'.
Then you could add macro, include and loop support, for more fun...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCfy0Os/YJ43cSjHIRAhUjAJ40eH5z/mBT1SPNg8XOgoNXdh5RPgCgyzfW
j9yxa/cCWvwVHVfiephLiRw=
=ThLm
-----END PGP SIGNATURE-----
Post a reply to this message
|
|