issue DEFINE-OPTIMIZER, version 5

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 13 Mar 89 20:27 EST
    From: Barry Margolin <barmar@Think.COM>

    ... the real value of optimizers comes when they translate into calls
    to extra fast, internal functions. ...

What makes you say that you can't translate particular calls to
a user function into extra fast (even constant-time!) algorithms
based on domain-specific knowledge?

    Portable optimizers can't do this, and non-portable optimizers don't
    need to be defined using a portable mechanism.

I believe this claim is unsubstantiated and unsubstantiable. In many
implementations, internal functions have no special property that user
programs do not.  In some cases, that makes the optimizers that much
more important since most internal functions run a constant factor 
faster, but do not have any algorithmic leverage over user programs.
Optimizers are potentially able to do much better than built-in 
optimizations because they can use domain-specific information that
is beyond the power of even the proverbial SCC (Sufficiently Clever
Compiler).

Optimizers have been around for a -long- time. They are not new
technology. If we cannot adopt at least this much this time, I see
no reason why for CL 2000 we won't have the exact same arguments
raised and we -still- won't get anything.  On the other hand, if we
adopt them now we get years of field testing, and next time there
will be a lot of users with suggestions about how to improve them.
Some progress must be made incrementally -- but no progress is made
if the increment is zero.

The risks are very low. This proposal already says the optimizer
function has to be semantics-preserving, and that it might never be
called. It's hard to see how that can go wrong.

For so little cost and so much potential gain, I think it is worth any
associated risk.