Re: issue DEFINE-OPTIMIZER, version 5

[cperdue@Sun.COM (Cris Perdue)]

I think the spec for this is going to have to hedge on
whether optimizers defined in this way affect functions
in the LISP package.  Perhaps it would be acceptable
to say, "Defining an optimizer for a function in the LISP
package may affect some, all, or no calls on that function."

Barrett suggests that optimizers need to have precedence over
INLINE for a function.  This must surely be true.  Are we
to tell users to not declare a function INLINE because that
might calls not to be optimized?

Regarding the accessor primitive, the problems with that
are not much harder than the problems with DEFINE-OPTIMIZER.

For example, if it is permitted to define an optimizer on a function
in package LISP, then we specify that those are all NIL
as supplied by the LISP vendor.

The operations on optimizers are incomplete in the current proposal,
and adding a suitable primitive would fix that problem and let
users write portable code for testing for an optimizer, copying,
accessing, and moving.

I'm not at all sold on the argument that a primitive would
interfere with an implementation that wishes to have multiple
optimizers for the same function.  I see nothing in the current
proposal to support that capability.