Re: bison and/or antlr ?

George Neuner <gneuner2@comcast.net> writes:


> Just to be sure, you are referring to _semantic_ predicates? I have
> never had a need for them that couldn't be served by parameterized
> rules (which I consider a much cleaner solution). I do find
> _syntactic_ predicates to be indispensable, however.


No, I was actually referring to syntactic predicates. I agree that
they are sometimes indispensable, but they also put little loop-holes
in your grammar, where something in one context parses one way (means
on thing) and in a different context parses (means) another. The
problem is (particularly with PEG's, which are syntactic predicates on
steroids) is that there is no check to verify that you haven't
introduced some corner case you didn't intend to. I don't think that
there are any PEG generators that even warn you if some rule is
unreachable. That scares me.


How do you know if your parsers accepts exactly what you expect,
without testing it? (And, I agree with Knuth's quote that implies
simply proving something isn't enough, one needs to test also.) On
the other hand, one doesn't want to rely solely on testing either,
especially with something that specifies an infinite set. Perhaps, you
could do okay, if you built a tool that did coverage testing, so that
you could see that every rule in the grammar was used at least in one
circumstance. However, I'd still be partial to LL or LR theory where
you know that if you have no conflicts the grammar has a well-defined
meaning and that meaning can be trivially reconstructed from the
grammar. Five years from now, we may have an equally robust theory of
predicated grammars, and then I'll be equally confident. Just not
today.


By the way, I do feel the same about the precedence and associativity
declarations in LR parsing. They are great tools, but not for use
with abandon. They also drop you off the cliff where your tool can't
tell you that you have mis-specified what you want. Used with care
that's okay. However, it is too easy to program carelessly.


That be said, Yacc++ supports all of the above, and is likely to
support GLR parsing in the future also. However, just because we put
a chainsaw in the operating room, doesn't mean that we want the
surgeon to use it when a scalpel is the appropriate choice.


Enough of my opinions for one day,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)

Return to the comp.compilers page.
Search the comp.compilers archives again.