Re: yacc for Pascal, was Why LL(1) Parsers do not support left recursion?

Hans-Peter Diettrich <DrDiettrich1@aol.com> writes:


> My dream were a tool which reads in a grammar, possibly in precompiled
> form, and then interprets some input according to that grammar. It would
> be sufficient, in the first place, if the engine would create an parse
> tree, which then could be inspected and evaluated without language
> restrictions. Furthermore it were nice to have hooks, so that parts of
> the final parse tree can be processed, and possibly discarded, as
> appropriate for the actual application.


I think something pretty close to your dream exists and is called
GrammarForge (and was previously called meta-S) written by Quinn Tyler
Jackson. His goal is to have an engine where one can do everything at
the grammar level. Moreover, I think he borrowed the Visual-Parse++
IDE as a basis and has a pretty good interpretive solution.


There are other tools which approach your ideal from different angles,
such as CodeWorker, Harmony ISTB, and the DMS toolkit.


> Arthur J. O'Dwyer schrieb:


> > [then, on debugging yacc-alike parser generators...]
> [...]
> > Which I guess brings us back to "why are yacc-alikes so hard to
> > use?", which is code for "why are yacc-alikes targeted at system hackers
> > instead of normal people?", which practically answers itself: hackers
> > wrote yacc in the first place, and yacc is mainly used by hardcore
> > programmers who are going to spend a lot of time debugging anyway. :)
>
> You mean, I simply should use a different tool?
...
> > (And you're still better off than if the tools didn't exist at all,
> > right?)
>
> Well, yes and no. Yes, I'm happy if I don't have to write an parser
> generator myself, but no, I'm not really happy with a possibly
> unreliable tool. We spend so much time in discussing and constructing
> "safe" (unambiguous...) grammars, and in the next step we should rely on
> unsafe tools?
>
> > </software-engineering metadiscussion>


Not all yacc-alikes are targeted at super-human programmers. Still,
on the one hand it is pretty easy to write a yacc-alike with one or
two bells-and-whistles as a student project. As far as I can tell,
many of the yacc-alikes are simply that. I think it is even easier to
write a recursive descent parser generator, and so there are even more
of them around as student projects.


On the other-hand, having put about 15 years worth of effort into
Yacc++ and still not being happy with the results in all
dimensions--correction hardly being happy with the results in any
dimension, I think I can say that it isn't only laziness that makes
the yacc-alike tools hard to use.


I think the sad truth is after doing the easy part, e.g. implementing
what one can read in the Dragon book or Holub, the terrain gets steep
fairly quickly. Thus, most compiler-compilers get the easy part done,
but leave one struggling with the more subtle points.


However, I agree with Dodi on the point, one shouldn't be stuck with a
poorly debugged tool and no avenue of support.


-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

Return to the comp.compilers page.
Search the comp.compilers archives again.