|Re: Seeking recommendations for a Visual Parser to replace Visual Pars firstname.lastname@example.org (Marcel Satchell) (2008-03-28)|
|Re: LRgen, was Seeking recommendations for a Visual Parser to replace email@example.com (Paul B Mann) (2008-03-31)|
|Popularity of compiler tools, was LRgen firstname.lastname@example.org (2008-04-06)|
|Re: Popularity of compiler tools, was LRgen email@example.com (Jason Evans) (2008-04-07)|
|Re: Popularity of compiler tools, was LRgen TegiriNenashi@gmail.com (Tegiri Nenashi) (2008-04-08)|
|Re: Popularity of compiler tools, was LRgen firstname.lastname@example.org (Walter Banks) (2008-04-11)|
|Re: Popularity of compiler tools, was LRgen DrDiettrich1@aol.com (Hans-Peter Diettrich) (2008-04-11)|
|Re: Popularity of compiler tools, was LRgen email@example.com (2008-04-11)|
|Re: Popularity of compiler tools, was LRgen TegiriNenashi@gmail.com (Tegiri Nenashi) (2008-04-11)|
|Re: Popularity of compiler tools, was LRgen firstname.lastname@example.org (2008-04-11)|
|From:||Hans-Peter Diettrich <DrDiettrich1@aol.com>|
|Date:||Fri, 11 Apr 2008 15:57:04 +0200|
|References:||08-03-107 08-03-119 08-04-024 08-04-031|
|Posted-Date:||11 Apr 2008 16:45:23 EDT|
Tegiri Nenashi 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
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
Return to the
Search the comp.compilers archives again.