Issue: CONSTANT-COMPILABLE-TYPES (Version 5)

[cperdue@Sun.COM (Cris Perdue)]

David Moon had a number of valuable comments on version 5.  This note
is to respond to them each in turn.

> I think this suffers from fundamental confusion between three distinct
> concepts:
>    (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 output of a single COMPILE-FILE.
>    (3) relation of two objects in the output of two different COMPILE-FILEs.
> All of these are important, but the answers are different.  I think they
> all have to be dealt with within one proposal, but the writeup for each
> datatype should be conscious of each of the three issues.

It is my desire to specify compiled constants using only the concept
of objects in the source code and objects resulting from COMPILE-FILE
followed by LOAD.  I have already modified the statement of parts of
the proposal to come closer to this goal.  In my opinion it would just
make the spec too much more complicated to introduce the notion of
"objects in the output" of a COMPILE-FILE or COMPILE-FILEs.  For those
who believe such concepts are necessary, how about waiting until
Version 6 appears before trying demonstrate that?

On cross-compilers: I think it is necessary to define "similarity as
constants" across address spaces as well as within a single address
space.  Note that rational numbers can be compared across address
spaces based on comparing the mathematical values represented, and the
same applies to truth and falsity.  I believe that the same can be
made to work for characters.  Similarity of aggregates of numbers and
characters can be specified in terms of similarity of their
componenents.  The spec attempts to define similarity of packages and
symbols basically in terms of comparison of strings also.

On uninterned symbols:  They are compared both by name *and* by EQ,
but we have to avoid saying that two uninterned symbols must be EQ to
be similar as constants, because this does not work across address
spaces.  At the same time if, say, a source code constant contains the
same uninterned symbol in two places, the resulting constant must
contain an uninterned symbol of the same name in the same two places.

Interned symbols: I've been trying to avoid splitting issues out
because it makes extra work for me, but I think handling of interned
symbols will have to be split out.  Personally I like the direction
proposed by Sandra.  I believe that binding a symbol name to symbols
in different packages at compiletime versus runtime has a lot more
potential for getting programmers into trouble than for solving their
problems.  (Note for example that inline functions are liable to be
bound at compiletime in any case.)

ARRAY-ELEMENT-TYPE:  I am correcting the proposal to require element
types to be "EQUAL-TYPEP" (the function David mentions as missing from
Common Lisp).

Adjustable arrays: Since the discussion of adjustable and simple
arrays at the January X3J13 meetings, I understand David's point, and
have modified this part of the proposal.

Structures:  Yes, similarity of structures must be revisited.  David's
suggestions look entirely plausible.

Hash tables: There is a relationship with EQUALP, as suggested.

Readtables:  Everyone seems to realize that there is a problem due to
functions in readtables.  If a readtable contains only symbols
representing functions rather than function objects, it could be
considered dumpable.  On the other hand, if I don't hear any support
for supporting readtables, readtables will be dropped from Version 6.

Functions: Yes, the statements about functions don't hack it.  At this
point compiled functions are not to be supported in compiled
constants.  I guess functions will not be supported at all in compiled
constants unless someone else works to make it so.