Re: Object-oriented parsers

In article 91-08-145 whatis@gnu.ai.mit.edu (Steve Boswell) writes:
>Lexical/syntactic/semantic style parsing, while affording division of labor,
>is really only suited to procedural programming properties.


Yes, but I'm not sure I see how your approach still provides us with that
very important division of labor. (See below for details.)


...Text + example of class hierarchy deleted...


>Thus, once an identifier is lexed, the symbol table can be consulted and
>the proper descendent of IDENTIFER_BASE can be created and attached to
>IDENTIFER (or returned by IDENTIFIER if IDENTIFIER is a pure parsing class.)
>IDENTIFIER is allowed to know about all the descendents of IDENTIFIER_BASE.
>Then dynamic binding on the resulting types can be used to weed through the
>possibilities in whatever rule is being parsed.


...Simpler example of class hierarchy deleted...


>The parsing method of STATEMENT would have to tell whether an initial
>IDENTIFIER starts an ASSIGNMENT or PROCEDURE_CALL.


...CLOS code fragment deleted...


>So by dynamic binding, the correct parsing method would be called.


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!?! 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 see where this approach might be acceptable if you are
designing a compiler for a language whose definition (i.e., minimally
grammar) is already set in concrete (e.g., C, Ada, etc.) but I don't think
that I would want to use this approach to design a language on-the-fly.
Perhaps it's just my ingrained notion to think of languages in terms of
(BNF) grammars rather than in terms of inheritance. If I did choose to
use your design approach, I certainly would NOT want to do it with a
"compiled" OOPL such as C++. It would take me [personally] all day to get
the inheritance of my classes correct. (Either that or I'd have to have
one heck of an incremental compiler.) 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.)


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?)


Note: The following comments are NOT aimed at anyone in particular, especially
Steve. There are simply my own $.02 worth.


While I find all this discussion on OO approachs to parsing interesting,
for *most* (i.e., read "[close to] LALR grammars") languages, I think that
the typical approach of separate lexers, syntactic analyzers, semantic
analysis, etc. is sufficient. I think we shouldn't re-invent the wheel.
I.e., use what works. In addition, compiler technology (w/ the exception
of error recovery and code optimization) is a fairly well understood
application. It is taught to all CS (under?)grad students. I think while
this might make for a nice research area, it is of little practical value.
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?
:-)


I for one, find this a case of simply trying to shoe-horn a problem into
an OOD. I always say (sometimes) "use the paradigm that fits the problem;
don't try to fit the problem to the paradigm".


--
In person: Kevin W. Wall AT&T Bell Laboratories
Usenet/UUCP: {att!}cblph!kww 6200 E. Broad St.
Internet: kww@cblph.att.com Columbus, Oh. 43213
--

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