issue CONSTANT-COMPILABLE-TYPES, version 8

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

I apologize in advance for the length of this message.

This is good except for a few typos and the controversial business about
functions.  I'd really like to see another round of editing to clean up
these problems before we're asked to vote on this.

I suggest moving everything having to do with functions to a
separate proposal.  What's currently in the body of the proposal for
functions does not make any sense to me.  I basically agree with the
comments from both Loosemore and Gabriel about this quoted in the
discussion section.  However, we need to be careful when we discuss this
to distinguish between a function as a constant in compiled code, and a
form whose result is a function appearing in compiled code.  The former
is `(quote ,#'(lambda ...)), the latter is `#'(lambda ...).  The meaning
of the latter is clear, of course, and a useful question would be
whether it can fully satisfy the need for functions in compiled code and
eliminate any demand for the former.

I've said this before, but I still think the proposal would be
easier to understand if it explicitly dealt separately with
  (1) relation of objects in the input of COMPILE-FILE to corresponding
  objects in the result of LOAD of the output of COMPILE-FILE.
  (2) relation of two objects in the result of LOAD of the output
  of a single COMPILE-FILE.
  (3) relation of two objects in the result of LOAD of the output
  of two different COMPILE-FILEs.
instead of smushing these together in a fuzzy way.  Look at the discussion
of uninterned symbols, for example: I found it incomprehensible.

Typos:

  For any object that
  appears in a constant, but is not supported by the language as part of
  a constant, the behavior of the compiler is unspecified; either the
  the compiler and/or loader will handle that constant (in an
  implementation-dependent manner) or the compiler will detect the
  situation and signal an error.

This says that the behavior of the compiler is unspecified and then
proceeds to specify it!

  Because hash keys can be aggregate objects and because we treat hash
  tables as unordered sets of <key, value> pairs, similarity of hash
  tables is more complex.  See under "Hash Tables", below, for the
  definition.

I have no idea how this paragraph got into the middle of the discussion
of uninterned symbols.

  References to packages are permitted in any constant.  

This sentence is redundant, or else it implies that references to some
other types are permitted in some constants but not in other constants,
which I don't think you intended.

  At load time, the package becomes the same as returned by

I don't know what it means for a package to "become".  I think
this is just fractured syntax, though.  See again my suggestion
for distinguishing the three types of similarity, which I think
indicates how to rewrite this sentence to be clear.

Under hash table:
  The table's test is unchanged also.

Unchanged from what?  I think what this was supposed to say was
that the table's test is a "basic attribute."

   Consider a hash table as an unordered set of key and
   value pairs.  Two hash tables are similar as constants
   exactly if there is a one-to-one correspondence between
   the key and value pairs of each and a one-to-one
   correspondence between the uninterned symbols of each
   such that the two keys of each corresponding pair are
   similar as constants and the two values are also similar
   as constants.  The correspondence of uninterned symbols
   must be consistent with the correspondence defined for
   the entire set of constants in the file.

This paragraph is totally garbled.  If you took out the
stuff about uninterned symbols it might make sense.

Structure, Standard-object
             <<There is a cl-cleanup issue, LOAD-OBJECTS, pending
             which proposes a mechanism for dealing with objects.>>
             For structure instances with no method defined at compile
             time for MAKE-LOAD-FORM, the slot values and the name of
             structure type (a symbol reference) are recorded by the
             compiler and reconstructed by the loader.

The text not enclosed in french quotation marks directly contradicts
the LOAD-OBJECTS proposal.  It should be removed so we don't have two
proposals trying to talk about the same thing.

This sentence in the discussion section:

  The full extension of the concept of coalescing of constants is to say
  that they can be coalesced exactly when they are similar as constants.

seems to be in the wrong document, since this issue is not about
coalescing of constants and does not otherwise mention it, except
incidentally in connection with a bug in Coral Lisp.