[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
optimization in the spec
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: optimization in the spec
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 13 Nov 87 14:18 EST
- In-reply-to: <871111150223.5.GREGOR@SPIFF.isl.parc.xerox.com>
Date: Wed, 11 Nov 87 15:02 PST
In the latest draft of the spec, there are several places which
explicitly address legal optimizations an implementation might perform.
I find these somewhat confusing, and I think that instead we might want
to do the following:
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'.
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'.
I think organizing it this way would be a good idea, although it could
involve a lot of work for a relatively small benefit. Also, in some cases,
such as object creation, it needs to be noted directly in the document that
the semantics have been relaxed to allow for increased optimization. This
was a very deliberate decision by the group, as I recall.
I don't have a good feel for whether it's better to describe these things
in terms of "optimization", as we do now, or simply to say that it is
implementation-dependent. The former way has the advantage of motivating
the reason for not requiring a particular behavior, while the latter is
more like CLtL.
As a start on this, here is a first crack on the law.
In order to insure program portability, there are strict rules which
must be followed when doing optimization of CLOS implementations. The
rules governing when error checking and signalling can be optimized away
have already been covered. Except where it is explicitly stated that
under certain compilation conditions it is permissible not to signal an
error, the rule governing optimizations is that no optimization can
change the behavior of a program. All optimizations must preserve the
semantics of the CLOS.
This is just a motherhood statement and begs the question "what, precisely,
are the semantics of CLOS."
to make it clear that no user program will be able to detect
optimization (except for the stuff about an error should be signalled).
Of course user programs will be able to detect optimization, because we are
giving access to implementation-dependent details, for instance through the
meta-object protocol. Your statement is almost as strong as "it is impossible
to write a Common Lisp program that is not portable." I think what you really
mean is that CLOS defines a certain semantics that portable programs can
depend on, and optimizations, like everything else, must conform to that
semantics. That portable semantics does not fully specify every detail of