Re: Issue: DEFINE-OPTIMIZER

[Rob.MacLachlan@WB1.CS.CMU.EDU]

   Date: Thu, 29 Sep 88 12:02 EDT
   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
   Subject: Re: Issue: DEFINE-OPTIMIZER 
   To: pierson%mist@MULTIMAX.ARPA

   [...]
   I was talking more about adding a style warning saying that the effects
   of writing optimizers on functions that you didn't implement may not be
   good because optimizers may already exist which you're defeating.

   This would leave it in the "unspecified but `harmless'" territory of the
   new error terminology Kathy Chapman has been circulating. I'd rather
   have it that way than "is an error" so that implementations wouldn't
   signal gratuitous errors when you were dissatisfied with their
   performance [...]

I'm afraid that it may be hard to guarantee that it is "harmless" to add
source transforms that potentially interact with existing (unknown builtin)
transforms.  The biggest snare that I see is the possibility for an "infinite
optimization loop" at compile time.  If your opimtizer decides to
left-associate +, and a builtin optimizer decides to right-associate, then
they are going to fight forever.

Consider also an implementation that transforms (1+ x) to the canonical
form (+ x 1), and a user "optimizer" that transforms (+ x 1) to 
(1+ x).

I think that it is perfectly reasonable to consider the addition of
transforms to builtin functions to fall in the same category as
redefinition of builtin functions: something not done by portable programs
(result undefined).

  Rob