compiling E: Phases of Transformations

[Mark S. Miller]

At 08:58 AM 8/8/00 , Monty Zukowski wrote:
> >I don't have anything like textual file inclusion, so I don't think I have
> >*this kind* of nesting.
>
>... or what about being able to
>debug each stage of your transformations?  You know you will want to look at the
>output of a particular pass to debug it, and you will want a way to identify the
>line in that particular pass based on the kernel-E.

I will certainly want this in developing the compiler.  However, users of E 
will want this rarely enough that, based on my experience using other 
languages, I feel happy with the following low-tech approach:

Whatever stage you'd now like to debug at, capture the printed form of this 
stage as text, and paste it back into the programming environment as source 
text to be executed.  Because our source-to-source transformation must 
(as one condition of correctness) at least preserve the semantics of the 
program, when understood simply as an E source program, such copy-paste must 
always work.  I saw a comment somewhere in the TwoBit literature (the Scheme 
compiler I think Dean is referring to), that, in developing the compiler, 
they derived the same benefit for the same reason.

This also provides a minor distinction between the #line approach and the 
others.  In the #line approach, the programmer would have to remove the 
#line directives before feeding the program back in.  I remember doing 
precisely this with cfront output when I wanted to debug at the generated C 
level.  This can be used to argue either pro or con the #line approach, but 
not strongly in either direction.


         Cheers,
         --MarkM