Issue: DEFINE-OPTIMIZER

[Jim McDonald <jlm@lucid.com>]

    If all you're saying is that people shouldn't write optimizers
    on functions they didn't write, I'm happy to stipulate that.

That's the sentiment I want to express, but at the same time, I
wouldn't want to discourage the use of optimizers such as:

(dotimes (i n) (incf sum i)) => (incf sum (truncate (* i (1- i) 2)))

Optimizers such as this are likely to be too specific to be worth
including in a vendors general development environment, yet could
help tremendously in particular cases.  

Perhaps one can only say this is an advanced feature and point out
some potential pitfalls... 

I should note that Lucid's compiler-macro facility allows one to
define a symbol to be treated as a function at eval-time but a macro 
at compile-time.  One obvious use of compiler-macros is to implement
optimizers.  The drawback is the one I alluded to earlier -- there is
just one compiler-macro for a symbol, so you run the risk of a
brain-dead dotimes if you try to optimize it as in my example above.

(I'd be tempted to suggest a compiler-macro-time analog to defadvice,
 but that seems too hairy, too dependent on the whole idea of
 compiler-macros, and too fraught with the dangers I railed against
 earlier.)

Overall, I think the proposal is a good idea if it is viewed as
a pre-pass before normal compiler optimizations, and if people are
discouraged from tampering with forms unless they understand all
the implications.  It should be clearer about its interaction with
macros.

I think there is room for a second, more controversial, proposal
that would provide a facility for advising the compiler with
optimization rules to be used internally, since compiler-macros,
beta-transforms, constant-folding etc. could reveal forms suitable for
user-defined optimizations.  

  jlm