|Compiler Design + feedback firstname.lastname@example.org (Philip Herron) (2009-04-21)|
|Re: Compiler Design + feedback cfc@shell01.TheWorld.com (Chris F Clark) (2009-04-21)|
|Re: Compiler Design + feedback email@example.com (Philip Herron) (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)|
|From:||russell kym horsell <firstname.lastname@example.org>|
|Date:||Thu, 23 Apr 2009 05:24:40 +0000 (UTC)|
|Organization:||Central Iowa (Model) Railroad, Plano, TX, USA|
|Posted-Date:||24 Apr 2009 06:49:33 EDT|
Chris F Clark <email@example.com> wrote:
> 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 control
> > 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".
Now this is a rule I wished all language designers/implementers would follow.
I had the displeasure to recently use a preprocessor in which the "directives"
were sometimes executed immediately, and sometimes altered internal options
and acted on at the end-of-input by the preprocessor.
While this doesn't sound TOO bad, the doc for the system didn't make it clear
which did what and, in fact, examples included with the package suggested
that all directives operated on a "store and later interpret" basis (i.e.
the logical way :).
To get even a basic thing to work involved trying non-trivial (no joke-- I
had to write a script to do it) interleavings & permutations of directives
to find out what did what (or in many cases just got an unremarked s/w
Return to the
Search the comp.compilers archives again.