Re: Object-oriented parsers

In article 91-08-148 kww@cblph.att.com (Kevin W Wall) writes:
>I may be missing something here, but what I think you are saying is that
>the language's grammar for which you are buiding a parser is implemented
>via the class inheritance lattice!?!


Mostly, yes. It keeps the grammar implementation abstract and it's
very extendible (which is one of the main benefits of OOP anyways).


>Maybe I'm just old fashioned but I think parser generators based on
>(extended) BNF notations (e.g., bison, yacc++) are a bit easier to change
>if all you want to do is tweak the grammar a bit.


I disagree. Shift/reduce and reduce/reduce errors are a pain in the
arse, especially when the semantics of the language could resolve the
ambiguity. Tweaking the grammar in big ways (e.g. adding a new type
of OPERATION called ONCE for Eiffel) is comparatively easy.


>I think that you definitely would need an OOPL that was well suited to
>prototyping to be able to construct an "as-yet-undefined" language in
>this manner. (No doubt one reason you thought CLOS to be suitable.)


Actually, the only reason I suggested CLOS was that it allowed dynamic
binding on its arguments and not just the object. (I know C++ does
too, but I personally dislike C++.) This approach would also lend
itself to languages being extended/redefined, which languages tend to
do now and then.


>Another thing which I don't understand is how you would do error recovery
>using a class inheritance model. (I.e., how does you parser recover when
>it sees a syntax error?)


I haven't worked that out yet (or that far ahead yet) but I would
guess that being able to do it in a programmed way would be better
than bison's "error" token (which, as I recall, if you place it in the
wrong place, it will cause s/r and/or r/r errors.)


>In particular, is there anything that an OO approach can do that the more
>traditional approaches CAN'T solve, or even solve just as easily? (Do we
>write a FORTH interpreter by changing the inheritance lattice on the fly? :-)


Yes -- the same reasons you use OOP over structural methods apply here
-- extensibility, reusability, dynamic binding. You CAN do it either
way, but which is easier for the programmer?


I also wasn't suggesting changing the inheritance lattice "on the fly" (do
you mean as the compiler is running?) That's highly intriguing though... :-)
--
Steve Boswell
whatis@ucsd.edu
whatis@gnu.ai.mit.edu
--

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