Compiling E: Phases of Transformations

[Monty Zukowski]

> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Monday, August 07, 2000 11:43 PM
> To: Monty Zukowski
> Cc: kenkahn@toontalk.com; E-Lang; Alexander Maneev; Igor Artyhov
> Subject: RE: Compiling E: Phases of Transformations
>
> Actually, as I mentioned in my reply to Dean, this is where I
> lied.  E does
> not currently have an equivalent of a #line directive, but perhaps it
> should.  Instead, E parse nodes point at an optional source position
> description
> http://www.erights.org/javadoc/org/erights/e/elib/base/SourceS
> pan.html .
> This includes not just a line number, but, imitating
> Smalltalk and Joule, a
> character span.  In any language in which multiple
> expressions can occur on
> a line, it is *much* better for the debugger to highlight the
> specific
> expression rather than the entire line.

Agreed.

>
> >Line directives would be useful for parser generators and
> other things that
> >generate E.  This information could be kept externally to
> the program, too, to
> >avoid cluttering up the intermediate source code.
>
> If you keep it external, you need to be able to say what it
> corresponds to
> in the program.  This would seem to require giving each
> parse-node a unique
> identity.  Since parse-nodes are pass-by-copy (to enable
> mobile code), this
> could be unpleasant.

You don't really need to know the parse nodes, just how a span in one file maps
to a span in another file, since the error message will be printed in terms of
the file span, not the parse node.

> In the absence of #line-like directives, parser generators
> should still be
> happy to generate parse-trees with source positions in the
> grammar file.
> Likewise, were ANTLR to generate .class files instead of
> .java files, it
> could represent real source positions, and get many Java debuggers
> to display positions in the source grammar file with no extra work.

You know, this has an interesting case.  Grammar constructs get generated into
loops and conditionals, and to understand antlr's generated code you want to
look at the generated code but know also what the grammar element that generated
it was.  Hmm, this actually is probably best solved by comments instead of some
weird nested line directive scheme.

Also interesting is that generating .class files would go against one of antlr's
main philosophies--to generate human readable code.  Although I guess you should
be able to generate .class files and .java files simultaneously if desired.

Monty