issue CONSTANT-COMPILABLE-TYPES, version 8

[alarson@src.honeywell.com (Aaron Larson)]

    Some types such as streams are not supported in constants.  Put
    another way, an object containing one of these is not considered
    similar as a constant to any other object.  Some implementations may
    support them and define how they are treated.  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.

The part about "...is unspecified; either..." is somewhat confusing to me.
Is the intent of this to say that it will either "work", or an error will
be signalled at compile time?  I.e. it is illegal for the system to signal
an error at load time, or for the error to go unsignalled?  The
unspecified, harmless, undefined stuff is rapidly becomming a tar pit...

    Number

      If either of the two objects is a number, both must be of the same
      type and must represent the same mathematical value.

For Number and Character is there some reason why you don't use CL
functions in the definitions of similar as constants, e.g. "Numbers are
similar as constants iff they are EQL"?

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

Where did the symbols come from?