|Object-oriented parsers email@example.com (1991-08-29)|
|Re: Object-oriented parsers firstname.lastname@example.org (1991-08-29)|
|Re: Object-oriented parsers email@example.com (1991-08-30)|
|Re: Object-oriented parsers firstname.lastname@example.org (1991-08-30)|
|Object-oriented parsers email@example.com (1991-09-02)|
|Re: Object-oriented parsers firstname.lastname@example.org (1991-09-03)|
|From:||email@example.com (Steve Boswell)|
|Date:||30 Aug 91 05:28:21 GMT|
In article 91-08-148 firstname.lastname@example.org (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... :-)
Return to the
Search the comp.compilers archives again.