Issue: DEFINE-OPTIMIZER

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

I don't think the style warning is too strong.

The issue is not what you have to know about the internals of the function
being optimized, but rather what you have to know about the internals
of DEFINE-OPTIMIZER.

The proposal almost didn't make `escape velocity' (to leave cl-compiler
and get seen by x3j13) because of concern on the part of implementors
that people would try to optimize things in the system. This warning is
intended to put those fears to rest.

The issue is that the proposed definition doesn't tell you if the system
also has optimizers for a function and whether if you define your own you
will clobber the system's.  This again was an issue that nearly killed
this proposal on the first pass-- some people want their system optimizers
implemented in terms of this; some people want to do it the other way
around.  Rather than fight over it, it's better to just compromise on
a conservative definition.

For functions you wrote, you know no one has written optimizers in advance
so you won't be clobbering anyone's, regardless of how DEFINE-OPTIMIZER
is implemented. For anything else, you can't know for sure what the effect
of doing DEFINE-OPTIMIZER will be in all implementations, so it's best
left vague.

Implementations which provide a full set of meta-level operators for
inspecting the set of optimizers on a function would be within their rights
to (by virtue of that complete set) say you could do an optimizer on
functions you didn't write without feeling guilty. But even then I don't
think everyone would agree that it's still conceptually the right thing.

Anyway, my feeling is that if you pursue your gripe, you'll risk crushing
this fragile proposal and the community as a whole will lose because they
won't be able to write optimizers on -anything- because no operator got
voted in.

-----
I haven't studied the notinline issue enough yet to have an opinion.