Tegiri Nena**** wrote:
>> One explanation I have heard is that the compiler writers don't like
>> to make themselves dependent on a tool that may go away. OTOH, gcc
>> reverted from using bison-generated parsers to hand-written ones (at
>> least for C++ and C), and I very much doubt that the future of bison
>> was the reason for that.
C/C++ like languages are known for context sensitivity, so that bison
(as a LR parser generator) does not fit the requirements.
>>Maybe some other posters can provide additional insights into the use
>>or non-use of compiler tools and the reasons for this.
When it's easier to write an parser than a grammar, for some language,
then the usefulness of an parser generator becomes questionable.
> IMO there is not enough added value. Comparing writing parsing engine
> from scratch vs. using off the shelf product I always prefer the
> former. When chasing bugs it is much easier to find them in your own
> code than being at the mercy of the tool owner.
IMO chasing and fixing bugs in parser code is possible only in top-down
parsers, not in table driven bottom-up parsers.
> Next I find the whole
> code generation idea ridiculous. I simply refuse to believe a code
> generator can output a quality product. On large size grammar it can
> easily generate huge methods that could overflow JVM method size (I
> experienced with ANTLR).
OTOH a parser generator can be proofed for correctness, to a very high
degree, so that the generated parser code can be assumed to be correct.
Human coders can introduce typos, and can misinterpret or overlook parts
of a language specification. Automated parser generators are much more
reliable in this domain.
> Then there limitations on what kind of
> grammar a parser engine can accept, e.g. no left recursion, no
> ambiguity, etc. This is totally inacceptible: a grammar is a
> declarative specification of the language. Making a particular parser
> engine happy does not warrant tinkering with it.
That's a reasonable argument, but not against parser generators in
general, but instead for the use of an *appropriate* parser generator,
based on an *appropriate* formalism for the description of the desired
language.
When the user is free to define the language, then he can make the
language conform to some grammar type, so that parser generators for
such grammars can be used without further hacks. In such cases I prefer
to write LR(~1) grammars, from which top-down parsers can be generated,
with all according benefits, like the chance for chasing *grammar* bugs
in the parser *code*.
> Within a wider perspective I feel a general failure of parser
> technology to deliver a user friendly product. This is why we have
> horrors of XML filling the void.
IMO new languages should not be specified in an purely abstract way,
they also should be specified in a way that allows to generate
definitely correct parsers at the same time, without conflicts and
ambiguities.
DoDi
|
