issue DEFINE-OPTIMIZER, version 5

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

I generally like DEFINE-OPTIMIZER:NEW-FACILITY, but I would like
to suggest a couple of changes.

I'm not a fan of documentation strings, but shouldn't DEFINE-OPTIMIZER
allow them?  Was their omission accidental or intentional?

Instead of returning two values from the body, I suggest returning one
value, or NIL to decline to optimize.  If an optimizer wishes to
optimize into a form whose result is NIL, it should return (QUOTE NIL).
After all, if it wishes to optimize into a form whose result is FOO, it
has to return (QUOTE FOO), not FOO.  The two values returned by
OPTIMIZE-EXPRESSION-1 are okay, since they are compatible with the two
values returned by MACROEXPAND-1.  A reasonable alternative would be to
eliminate the two values at all levels, and also eliminate the special
casing of NIL, and simply specify that one declines to optimize by
returning the original form (compared with EQ).  This will work but is
slightly more awkward for the optimizer writer, since &WHOLE would
have to be used.  I'd accept this alternative if more people are in
favor of it, but I prefer special-casing NIL.  I'd greatly prefer either
of those alternatives over what the proposal says now.

It isn't made clear whether OPTIMIZE-EXPRESSION returns one value
or two.  It should be consistent with OPTIMIZE-EXPRESSION-1.

  Using FLET and MACROLET shadow...

I assume it was only accidental that LABELS, GENERIC-LABELS, and
GENERIC-FLET were omitted from this list.  I am unable to figure
out whether WITH-ADDED-METHODS should be included in this list
or not; I suspect not.

The similar Symbolics Genera facility allows more than one optimizer
to be defined for a given function; the optimizers are invoked in
unspecified order until one succeeds.  This feature is actually
used, however I think it is okay to leave it out.

I agree with Barrett's comments quoted in the discussion section.
I'd like to see the proposal amended the way he suggests.