|Writing Grammars firstname.lastname@example.org (Tim Newsham) (2002-07-25)|
|Re: Writing Grammars email@example.com (Ira Baxter) (2002-07-31)|
|Re: Writing Grammars firstname.lastname@example.org (Mark) (2002-07-31)|
|Re: Writing Grammars email@example.com (Peter H. Froehlich) (2002-07-31)|
|Re: Writing Grammars firstname.lastname@example.org (Tim Newsham) (2002-08-04)|
|Re: Writing Grammars email@example.com (SLK Parsers) (2002-08-04)|
|Re: Writing Grammars firstname.lastname@example.org (VBDis) (2002-08-10)|
|From:||"Peter H. Froehlich" <email@example.com>|
|Date:||31 Jul 2002 01:16:43 -0400|
|Posted-Date:||31 Jul 2002 01:16:43 EDT|
On Thursday, July 25, 2002, at 08:24 , Tim Newsham wrote:
> It seems pretty typical in compiler (and other parsing) implementation
> that you would:
> - start with a grammar of the language
> - modify the grammar to be easy to parse (ie. LALR(1))
> My question is: Are there any tools or research into tools to help
> automate the process of going from step 1 to step 2. It seems that
> this is a very difficult and error-prone step. Basically, software
> that would perform the same types of transformations that a human
> would perform on the grammar.
I am not aware of anything like that, but I would like to make a
"position statement" instead. I don't think that these "two steps"
should exist like you describe them. To me it seems that the "proper"
way to do things is to decide on an abstract grammar and the
semantics, and then design a concrete grammar for it that is suitable
for a certain parsing method. Nothing particularly "error prone" in
this approach. Of course it does not work that well if you implement a
language that someone else designed/defined.
Peter H. Froehlich ->[!]<- http://nil.ics.uci.edu/~phf/
OpenPGP: D465 CBDD D9D2 0D77 C5AF 353E C86C 2AD9 A6E2 309E
Return to the
Search the comp.compilers archives again.