|[2 earlier articles]|
|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)|
|From:||Tegiri Nenashi <TegiriNenashi@gmail.com>|
|Date:||Fri, 11 Apr 2008 17:00:09 -0700 (PDT)|
|References:||08-03-107 08-03-119 08-04-024 08-04-031 08-04-041|
|Posted-Date:||11 Apr 2008 22:39:12 EDT|
On Apr 11, 9:52 am, idbax...@semdesigns.com wrote:
> 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.
Isn't GLR exponential in the worst case? I settled on CYK. Three
nested loops, even a sloppy programmer like me can implement that!
Then there are optimization tricks to speed things up a little...
I also checked Earley, but [contrary to what literature suggests] I
was unable to make it competitive to CYK. CYK optimizations clearly
fail to apply to Earley, and unlike CYK where syntactically incorrect
input still can be processed into a forest I failed to figure out how
to do error recovery for Earley.
> > 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.
Again this is true for well packaged products, and I don't see them on
the market. The mature and best documented products like ANTLR suffer
from the above deficiencies, while GLR, Earley, or CYK based parser
engines are rare, experimental and likely be unavailable for
implementation language of my choice.
Return to the
Search the comp.compilers archives again.