Re: optimization in the spec

[kempf%hplabsz@hplabs.HP.COM]

>   1- Have an general, well worked out statement about what kinds of
>      optimization are legal in CLOS implementations.  This statement
>      would be 'the optimization law'.

I think the general statement should be that no implementation should
perform an optimization which could cause a change in CLOS semantics.
This statement might, in fact, be TOO general, since it might rule
out things like in-lining slot access, which would cause the class
changing protocol to break. But in-lining slot access is a natural
optimization to want to do after code has been developed and the 
class definition stabilizes, when the class changing protocol doesn't
matter any more. . So maybe the statement needs to be tied to the safety level.

>   2- Have an appendix or implementation notes in the document reflecting
>      places in the design where the intent was to allow optimizations
>      that are in accordance with the 'the optimization law'.

This is a good idea. The hints on optimization scattered about the
document should probably be gathered into an implementation notes
appendix, or (less preferable) set off from the text as in CLtL.