optimization in the spec

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Wed, 11 Nov 87 15:02 PST
    From: Gregor.pa@Xerox.COM

    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."

    We need
    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
CLOS execution.