Re: Idea: New way for optimizers to work

[RMS at MIT-AI (Richard M. Stallman)]

If the user redefines a function because he wants to recycle the name,
and he doesn't care about the old meaning, then the right thing is to
get rid of old optimizers.  If the user redefines a function because
he is fixing a bug in the old definition, or adding a feature, he
probably wants to keep the old optimizers (though he may need to fix
them as well).

I don't think there is any hope that the system can second-guess the
user and always do the right thing.  So here's a way that the user can
conveniently tell the system which is right:

Perhaps the optimizers should be properties of the definition
rather than of the function name.  That is, they could live
in the "debugging info alist" which is essentially a plist
for the function.  To make this win, the optimizer definitions
would have to appear with the function or macro definition.
They could not be put on separately.  Then re-evalling the same
definition, modified, would re-install the same old optimizers,
whereas a totally separate definition would have its own list of
optimizers.  The usual style would be to define separate functions
to do the work of the optimizers and supply their names
in a local declaration in the definition of the function to
be optimized.

Any comments?