Re: optimizers

[RMS at MIT-AI (Richard M. Stallman)]

I can't understand all of the things that JONL says are wrong
with optimizers on the Lispm.
As far as I do understand them, 
1) There is no problem with EQ tests.  Displacing macros have
nothing to do with this -- the Lisp machine also has them,
and that proves experimentally that they are no problem.
The reason they are no problem is that optimizers aren't macros
and we don't have (or need) displacing optimizers (since they
only affect compilation).
I think it is much cleaner just to return the transformed form
(not to mention much better for compatibility!) so I'm against changing them.
2) I would not object to a def.. function to define optimizers.
I don't see why it should warn about putting optimizers on something
which is not FBOUNDP. I don't think that the order of defining the
optimizers vs the function should matter.  Also I don't understand
the suggestion about creating a definition which prints a warning
in interpreted code.  The lack of a definition ought to do that anyway.
3) I don't believe it is right for DEFMACRO to check in any way for
the existence of optimizers, because it is wrong for redefining the
function (either macro or not) to flush the optimizers.  If I re-eval
a corrected definition of a function, I don't want that to flush the
optimizers.
4) "optimizers" is precisely appropriate for source transformations
which happen only in the compiler.  These are used for nothing except
optimization of things which could instead compile into function calls
that would be much slower (and might require some variables to be
special).  For example, this is how DO and MAP get open-coded.
And a lot of other things that would be "cretinous code" but not
complete disasters if they were not optimized.

If we decide also to have source to source transformations that also
apply in the interpreter, then they could be essential parts of the
definition of something, and they shouldn't be called "optimizers".
In any case they could not be called "optimizers" because the
existing optimizers are definitely intended to be used only by
the compiler.

Anything which is used only by the compiler has to be a form
of optimization since it can't be an essential part of the definition
of the function it applies to.

PS. The reason why just returning the transformed form is better
for compatibility is that it doesn't require multiple values.