|Re: Seeking recommendations for a Visual Parser to replace Visual Pars email@example.com (Marcel Satchell) (2008-03-28)|
|Re: LRgen, was Seeking recommendations for a Visual Parser to replace firstname.lastname@example.org (Paul B Mann) (2008-03-31)|
|Popularity of compiler tools, was LRgen email@example.com (2008-04-06)|
|Re: Popularity of compiler tools, was LRgen firstname.lastname@example.org (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 email@example.com (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 firstname.lastname@example.org (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 email@example.com (2008-04-11)|
|Date:||Fri, 11 Apr 2008 10:52:35 -0700 (PDT)|
|References:||08-03-107 08-03-119 08-04-024 08-04-031|
|Keywords:||tools, parse, comment|
|Posted-Date:||11 Apr 2008 16:47:51 EDT|
On Apr 8, 3:13 pm, Tegiri Nenashi <TegiriNena...@gmail.com> wrote:
> On Apr 6, 8:25 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> > - Finally, many compiler writers seem to dislike tools (or maybe none
> > of the tools are good enough or something).
> 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.
This is the excuse offered by every programmer I ever met, for why he
has to roll his own whatzit. It completely fails to account for the
fact the the existing whatzit has vast amounts invested by others to
get it right and to handle the strange cases.
> Next I find the whole code generation idea ridiculous. I simply
> refuse to believe a code generator can output a quality product.
Er, you don't like GCC?
> On large size grammar it can easily generate huge methods that could
> overflow JVM method size (I experienced with ANTLR). 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.
You certainly don't want a tool that springs a surprise on you after
you have deeply invested in it. I always thought the JVM module size
limit was just dumb; all the JMP technically needs are a few "long
address" opcodes in the JVM.
The other limitations: no left recursion, no ambiguity, are all solved
by good parser generators. I highly recommend GLR, which is what we
use for DMS. None of the above limitations apply.
> 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.- Hide quoted text -
I continually am amazed that people get hung up on the parsers. I
guess they just never get past it.
For any really interesting langauges, like poker, you have to ante up
a parser, that isn't where the real problems are. You need tree
building, preprocessor support, multiple compilation unit support,
name/type resolution, control/data flow analysis, semantic analysis
based on that awful reference manual for that screwball dialect, ....
And having spent a decade implementing integrated machinery to do all
this, I don't see how anybody can justify rolling their own whatzit.
Ira Baxter, CTO
[Some people are paid by the hour. -John]
Return to the
Search the comp.compilers archives again.