[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue CONSTANT-COMPILABLE-TYPES, version 8
- To: firstname.lastname@example.org
- Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
- From: email@example.com (Aaron Larson)
- Date: Sun, 19 Mar 89 18:19:20 CST
- In-reply-to: Sandra J Loosemore's message of Mon, 13 Mar 89 09:12:49 -0700 <8903131612.AA02083@defun.utah.edu>
- Posted-date: Sun, 19 Mar 89 18:19:20 CST
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...
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?