|References to object oriented design of compilers? email@example.com (1993-10-16)|
|Re: References to object oriented design of compilers? jones%pyrite@uunet.UU.NET (1993-10-18)|
|Re: References to object oriented design of compilers? firstname.lastname@example.org (1993-10-19)|
|Re: References to object oriented design of compilers? email@example.com (1993-10-22)|
|Re: References to object oriented design of compilers? firstname.lastname@example.org (1993-10-25)|
|Re: References to object oriented design of compilers? email@example.com (1993-10-26)|
|Re: References to object oriented design of compilers? firstname.lastname@example.org (1993-10-26)|
|Re: References to object oriented design of compilers? email@example.com (1993-10-29)|
|From:||jones%pyrite@uunet.UU.NET (Douglas W. Jones,3193350740,3193382879)|
|Organization:||University of Iowa, Iowa City, IA, USA|
|Date:||Mon, 18 Oct 1993 19:13:15 GMT|
firstname.lastname@example.org (Peter Newton):
> Does anybody know of any publications on the subject of object-oriented
> design applied to compilers?
I don't know about any papers, but I've been using this method in an Ada
based simulation system. To use object oriented terminology instead of
Ada terminology, each syntactic class is associated with an object class.
To support parsing, each such object has the following methods:
isthis -- is the string starting at the current token an instance of
the indicated syntactic class. Called only if the
calling context allows for more than one class.
Strictly speaking, this is not object oriented, in
that it is just a boolean function (one such function
for each syntactic class).
parse -- consume the string starting at the current token (advancing
the token over the consumed string) until the whole
string of the indicated class has been consumed. This
is the initializer for the class. Parameters to parse
typically include a procedure parameter (or symbol table
object parameter) that conveys the current static
environment. There is no requirement that parameters
to the parse routines for different syntactic classes
be the same, except in those cases where the classes
are allowed in the same syntactic context.
evaluate -- given an abstract syntax tree node representing the
parsed item, and given, as parameters, the down parameters
passed in the attribute grammar, return the up parameters
in the attribute grammar. As L. M. Chirica showed over a
decade ago, any non-circular attribute grammar can be
converted to the functional form this technique requires,
and the result is equivalent to the denotational model of
additional methods are class dependant, and are usually passed as procedure
parameters to the evaluate or parse routines of subsidiary
phrases in the syntax tree.
In my application, the interpreter used in my simulator, evaluate is non
destructive. In a compiler, evaluate would tend to destroy the syntax
tree node as it completes the code generation for that node. The entire
syntax tree need not ever appear in memory, since the parse routine for
one class could decide it is time to evaluate the subsidiary clauses as
soon as they are parsed. In that case, only the current path from the
root to the current leaf needs to be stored, and it corresponds to the
push down stack of a traditional parser/translator.
Return to the
Search the comp.compilers archives again.