Re: Source-to-source transformations

[Guy.Steele at CMU-10A]

@Begin(Flame)
Well, certainly not all optimizers are source-to-source, but then
again just because a transform is source-to-source doesn't mean
it isn't an optimizer.
@End(Flame)
@Begin(Criteria)
If a special construct is adopted for defining optimizers, or
transformers, or whatever they are to be called, I think these
criteria should be observed:
@Begin(Itemize)
The name of the construct should begin with "DEF", primarily
for the sake of @.

The abbreviation TRANS should be avoided as being too ambiguous
(transform? translate? transsubstantiate? translucent? transporter?).
@End(Itemize)
Additionally, compatibility between all dialects concerned is
reasonably important, but may not be critical.  Should this be
released as a user-available feature, or is it for use primarily
by the compiler writer?  Currently most such transforms are
indeed written with an eye to the eventually produced machine code.
The user already has macros.  Introducing source-to-source transforms
provides the user with yet another way to make compiler and
interpreter behave differently if we aren't careful.
@End(Criteria)
@Begin(Opinion)
If we must have it, let's call it DEFTRANSFORM.  Let it not
become too hairy.  Letting it know the evaluation context
(EVAL, COND, or PROGN? so to speak) isn't a bad idea.  In fact,
maybe macros might want to have such an argument also?
@End(Opinion)