|Compiler Design + feedback email@example.com (Philip Herron) (2009-04-21)|
|Re: Compiler Design + feedback cfc@shell01.TheWorld.com (Chris F Clark) (2009-04-21)|
|Re: Compiler Design + feedback firstname.lastname@example.org (Philip Herron) (2009-04-22)|
|RE: Compiler Design + feedback email@example.com (Quinn Tyler Jackson) (2009-04-22)|
|Re: Compiler Design + feedback firstname.lastname@example.org (russell kym horsell) (2009-04-23)|
|Re: Compiler Design + feedback email@example.com (Pertti Kellomaki) (2009-04-24)|
|Re: PCC, was Compiler Design + feedback firstname.lastname@example.org (Jonathan Thornburg) (2009-04-25)|
|Re: PCC, was Compiler Design + feedback email@example.com (toby) (2009-05-10)|
|[1 later articles]|
|From:||Chris F Clark <cfc@shell01.TheWorld.com>|
|Date:||Tue, 21 Apr 2009 23:15:48 -0400|
|Organization:||The World Public Access UNIX, Brookline, MA|
|Posted-Date:||22 Apr 2009 03:52:13 EDT|
Philip Herron <firstname.lastname@example.org> writes:
> But for an interpreter should you like do the python way of doing
> things and just execute line by line, i just dont know how you conrol
> the flow that way of your program without parsing the entire source
> code into some kind of syntax map.
At some level, you eventually have to parse more than line-by-line
unless your language stays trivial. So, yes, it is a good thing to
parse then entire source into an internal representation. I once
wrote an article about this for Sigplan Notices called "Build a
Tree--Save a Parse".
That is not to say that many line-at-a-time processors don't have a
place. In fact, single pass compilers are kind of the ultimate
expression of this idea, and there is a lot you can do with them.
However, if you look under the hood, a single pass compiler is simply
building up a representation for something else. It is quite hard to
write a single pass interpreter for a sufficiently complex language.
On the other hand, it is often quite easy to write things
a-pass-at-a-time. You can often find something you can implement as a
single pass of your intermediate representation, and then another, and
another. There is an old joke about how many passes will an n-person
compiler teams write? The answer being, n-1 ... someone has to
coordinate the team.
Running passes over an intermediate (often tree-like) representation
of a source text, is such a powerful idea that it is formalized in
attribute grammars and the visitor pattern and tree rewriting systems
and probably a dozen other ways.
One attribute grammar system even minimized the number of passes. You
write your grammar using the equations that solve your problem and the
tool figures out the interdependencies and organizes the passes so
that it computes them in as few passes as possible.
Hope this helps,
Chris Clark Internet: email@example.com
Compiler Resources, Inc. or: firstname.lastname@example.org
23 Bailey Rd Web Site: http://world.std.com/~compres
Berlin, MA 01503 voice: (508) 435-5016
USA fax: (978) 838-0263 (24 hours)
Return to the
Search the comp.compilers archives again.