Compiling E: Phases of Transformations

[Monty Zukowski]

> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Wednesday, August 09, 2000 12:32 PM
> To: Monty Zukowski
> Cc: E-Lang; Alexander Maneev; Igor Artyhov
> Subject: RE: Compiling E: Phases of Transformations
>
>
...

> #3 (which I hadn't previously though of) is the equivalent
> for trees of
> using spans in text as the keys of a mapping.  It would work,
> but seems to
> be a lot of trouble.
>
> The known problem with #1 is that it encodes information in
> the parse trees
> that don't correspond to a printed form.  In light of the previous
> discussion of E's expansion of quasi-expressions, and the tentative
> conclusion that text + span-to-span mapping is the right
> interface there,
> perhaps the right answer to this objection is to provide a
> parse-tree-printing
> operation that generates both text and a span-to-span mapping
> that maps from
> this printed text to the original sources.
>
> Then, to re-answer the last email, the decision about what stage the
> debugger should display as source becomes a decision about
> which map we
> throw away.

That sounds workable to me.

> >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.
>
> Oh god, comments!  Another option!
>
> Actually, using the previous quasi-parser example, I think we
> can disqualify
> comments for the same reason we disqualified #line-like
> directives.  It is
> unreasonably burdensome on the definition of each
> quasi-grammar that they must
> understand any one universal (among quasi-grammars)
> commenting convention.
> Better to put the mapping on the side, in a separate argument to the
> compiler, than to impose this burden on all quasi-grammars.
> Making them all
> recognize ${<integer>} and such was bad enough.

I wasn't thinking of comments or #line in the quasi-parser input, rather
comments or #line directives in the generated E code for that parser, which
perhaps will actually be E parse trees.  You would need to pass the quasi-parser
the span of the quasi-parser text it is generating from, so the #line's would
all be relative to the original source code.

> How do you feel about the "which mapping do you throw away"
> approach for
> determining whether an ANTLR user debugs at the grammar level
> or the parser
> implementation level?

I like it.

> >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.
>
> How do you like the suggestion, in earlier email, of
> generating Java source
> plus a Java-source-span to grammar-source-span mapping, and
> then giving the
> ANTLR user the option to use this mapping to post-process the
> *.class file?
> The decision about which level to debug at becomes the decision about
> whether to post-process the *.class file.
>
> This approach requires no changes to or knowledge of the
> insides of any Java
> compilers.  Often, it can also be used with stock Java
> debuggers, without
> any changes or much knowledge.

This is definately worth looking into.  I think it would be the right way to do
it.

Monty