Re: Object-oriented compiler construction: ideas?

euahjn@eua.ericsson.se (Henrik Johansson)
14 Jun 1996 16:10:31 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: Object-oriented compiler construction: ideas? Arthur.Chance@Smallworld.co.uk (1996-06-08)
Re: Object-oriented compiler construction: ideas? dotw@centauri.cadre.nl (1996-06-08)
Re: Object-oriented compiler construction: ideas? bnm@indica.bbt.com (1996-06-08)
Re: Object-oriented compiler construction: ideas? nick@an-teallach.com (Nick Rothwell) (1996-06-08)
Re: Object-oriented compiler construction: ideas? darius@phidani.be (Darius Blasbans) (1996-06-08)
Re: Object-oriented compiler construction: ideas? poe@theory.lcs.mit.edu (1996-06-13)
Re: Object-oriented compiler construction: ideas? euahjn@eua.ericsson.se (1996-06-14)
Re: Object-oriented compiler construction: ideas? kalsow@winternet.com (1996-06-14)
Re: Object-oriented compiler construction: ideas? darius@phidani.be (Darius Blasband) (1996-06-21)
Re: Object-oriented compiler construction: ideas? rwatson@CAM.ORG (Richard Edward Watson) (1996-06-23)
Re: Object-oriented compiler construction: ideas? bronnikov@aol.com (1996-06-24)
Re: Object-oriented compiler construction: ideas? bobduff@world.std.com (1996-06-26)
Re: Object-oriented compiler construction: ideas? leichter@smarts.com (Jerry Leichter) (1996-06-27)
[9 later articles]
| List of all articles for this month |

From: euahjn@eua.ericsson.se (Henrik Johansson)
Newsgroups: comp.compilers
Date: 14 Jun 1996 16:10:31 -0400
Organization: Ericsson Telecom Systems Labs, Stockholm, Sweden
References: 96-06-047
Keywords: OOP

Oliver Plohmann wrote:
> When I first looked into a book about compilers I saw a parse tree with
> integers representing the respective keyword. I thought you could
> alternatively make up the parse tree of objects, like Statement,
> ConditionalBlock, Loop, etc. A ConditionalBlock would contain the


Darius Blasbans (darius@phidani.be) wrote:
: You can even take this idea further by having a NonTerminal root
: class, a Statement class derived from NonTerminal, an IfStatement
: class derived from Statement, etc...


poe@theory.lcs.mit.edu (Peter Orbaek) writes:
> I my experience this is not always the case. I did a compiler for the
> Action semantics description language in this OO style with essentially
> a class for each non-terminal in the grammar.
>
> The problems that I saw with this approach is the proliferation of
> lots on non-important classes corresponding to the needs of the
> concrete syntax to be LALR(1) (I was using yacc). I got into a maze
> of lots of little methods all alike, but syntactically dispersed
> because each of them needed to be a method.
[snip]


I am using the polymorphic approach myself, one class for each type of
node occuring in the parse tree. The problem stated by Darius Blasbans
is handled best by using the `Visitor pattern'. The node classes then
need only one method: `accept(Visitor)'. The burden is moved to the
abstract visitor class and its concrete derived classes, but the logic
of the code gets less dispersed.


--


Post a followup to this message

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