On Apr 8, 3:13 pm, Tegiri Nena**** <TegiriNena...@[EMAIL PROTECTED]
> wrote:
> On Apr 6, 8:25 am, an...@[EMAIL PROTECTED]
(Anton Ertl)
> wrote:
>
> > - 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 sup****t, multiple compilation unit sup****t,
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
Semantic Designs
[Some people are paid by the hour. -John]
|
