[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: optimization in the spec
> 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.