[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: optimization in the spec
- To: Gregor.pa@Xerox.COM
- Subject: Re: optimization in the spec
- From: kempf%hplabsz@hplabs.HP.COM
- Date: Thu, 12 Nov 87 15:37:57 MST
- Cc: email@example.com
- In-reply-to: Your message of Wed, 11 Nov 87 15:02:00 -0800. <871111150223.5.GREGOR@SPIFF.isl.parc.xerox.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.