Issue: DEFINE-OPTIMIZER

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

    Date: Wed, 28 Sep 88 16:40:39 PDT
    From: Jim McDonald <jlm@lucid.com>

	One of the nice things about Pitman's proposal is that it is general
	enough so that you could use it to implement the kind of rule-based
	approach you describe.  I tend to agree with Pitman that this is an
	advanced feature, and that people who use it will be willing and able
	to do that kind of thing.

    Does this mean it is fair to assume that if users want to use the
    feature across several ports, they will be willing to modify the
    (presumably incompatible) optimization routines supplied by different
    vendors, and that vendors will be encouraged to release the source
    code for their optimizers?   (Otherwise optimizers are likely to be
    quiet pessimizers, bypassing internal tricks.)

I think the way Symbolics does its optimizers (I haven't looked recently) is
to allow multiple optimizers on a function and to give each a name, so that
you can selectively redefine each. In effect, it defines

 INTERNAL-DEFINE-OPTIMIZER function optimizer-name bvl &BODY forms

so that (effectively) you could define DEFINE-OPTIMIZER as 

 (DEFMACRO DEFINE-OPTIMIZER (NAME BVL &BODY FORMS)
   `(INTERNAL-DEFINE-OPTIMIZER ,NAME ANSI-CL-INTERFACE ,BVL ,@FORMS))

If you have a pattern-driven optimization facility, you could either extend
it so each pattern gets a name and multiple optimizations on the same type
are possible to try (in case one has no effect) or else you could define
that the most specific of several optimizers hit. So DEFINE-OPTIMIZER could
define a pattern that matched anything and then you could define 
implementation-specific optimizers that did better.

I guess what I'm saying is that just because this appears to Common Lisp
users as a low-level substrate doesn't mean that it has to be implemented
underneath your optimization facility. It can still sit on top. So you
don't have to publish info about how your internal facility works. The
biggest risk is that people with portable optimizers might extend the
facility unnecessarily in some cases because they don't realize you have
more stuff around they could have linked into.

    I see nothing inherently wrong with that, but would like it to be clear
    that the level of portability may be very low,
    with parallel maintenance required for every vendor you port to,
    and that effective use will require a moderate amount of documention
    from the vendors.

I totally disagree. You certainly have not made any convincing case for
this at all.