issue DEFINE-OPTIMIZER, version 5

[rpk@goldhill.com (Robert Krajewski)]

I think a portable optimizer definer is a fine idea.  It's especially
useful for authors of Common Lisp-embedded subsystems that offer safe
access to their data structures in a development environment, but who
also wish to produce fast code for delivery.  In such cases, an
optimizer should only run when unsafe code is desired.

Assuming that optimizers are invoked no matter what the compiletime
parameters (except maybe a switch to turn optimizers off), it would be
useful if the optimizer could make inquiries about OPTIMIZE SPEED,
SPACE, SAFETY, and so on.  For example, Gold Hill Windows could turn a
call to WINDOW-X (a function which checks to see if its argument is a
window) into %WINDOW-X, a DEFSTRUCT-generated accessor which is
subject to further optimization.  However, such an optimization is
warranted only if the unsafe code is desired.  The optimization should
obtain only after an compile-time environment query is made.

I suppose the issue could be sidestepped if the subsystem advertises
compile-time parameters which are used by the optimizers.

(Another useful query is ``How many values are expected from this call ?''
but we'll leave all that for future standardization.)

Another issue: The documentation for the optimization for the facility
should make it clear that optimized form must preserve the Common
Lisp order-of-evaluation semantics of the form.  In other words,
optimizers like

(define-optimizer foo (x y) `(better-foo ,y ,x))

are bad.