[Masinter.pa: Handling Common Lisp built in types]

[Masinter.pa@Xerox.COM]

I found the old mail, but it isn't as relevant as I thought.  Just "for
the record" ....
I thought it was interesting to see what was "wrong" here.


     ----- Begin Forwarded Messages -----

Date: 18 Jul 85 07:43 PDT
From: Masinter.pa
Subject: Handling Common Lisp built in types

I think that we can regularize the handling of Common Lisp standard type
specifiers by categorizing them. I've been working on this for a while,
but still don't have it 100% right; but what do you think about the
general direction?


- - - abstract - - - - - - -
Abstract classes have no immediate instances, but are umbrellas for
various implementation-specific types. An :include of these types
inherits no structure or accessor functions.

atom, common, float, integer, t
array
vector
string
bit-vector
(array * (* * ...)) for between 0 and array-rank-limit *.

[Being able to :include these has implications for implementation of
vectorp, atom, etc.]

- - - virtual-structure - - - - - -
Some should be treated "as if" they had structure. An :include of these
inherits the slots as noted, and the corresponding accessor functions.
(Note that this may require special implementation, eg., if cons cells
are cdr-coded, but structures that :include them are not.)
Implementations may have other components, but the ones specified are
the only ones inherited.

cons (car cdr)
complex (realpart imagpart)
ratio (numerator denominator)
character (code bits font)

Except for conses and symbols, the slots are read-only.

Note: I'm reluctant to add 
symbol (plist package name) 
to this list. 
- - - - - implementation - - - - - - -
Some are implementation-specific classes, with no visible internal
structure. One cannot :include these, although they can be used in type
specifiers.

bignum, fixnum, double-float, short-float, single-float

(vector type *), (simple-vector type (n))
(array type [*|(*+)]), (simple-array type (n)),

when "type" is "OK" (implementation or abstract or immutable-predicate).
Note that (array t  (3 3)) is mutable, since you can displace an array.
{Do I understand this?}
(All vector and array constructed types excluding the ones allowed above
as "abstract". Note that we've made a distinction between "string" and
"(vector string-char)", requiring only that (vector string-char) be a
subtype of "string".)

- - - - - should-be-implementation - - - - - 
Some should have been specified as having distinct data types, but
weren't. We could propose changing the Common Lisp spec to make it so,
but it would probably cause some trouble.

stream, package, readtable, hash-table, pathname, random-state

(It would actually be reasonable to make these abstract types. The
problem is that their place in the class hierarchy is ambiguous. It
would be better if we could specify that those types are also disjoint
with number, array, symbol, list. They then could be "abstract with
unspecified implementation", i.e., one could :include them, but would
inherit no structure even though any implementation would have
structure.)
 
- - - - - - - immutable-predicate - - - - - - - -
These are predicates which don't rely on mutable properties, but are
still not usually thought of in the class heirarchy:

bit, (integer low high)
(mod n), (signed-byte s) (unsigned-byte s) (rational low high) (*float
low high)
(and type1 type2 ...), (or type1 type2 ...), (not type1)

(when the subtypes are OK, of course)
- - - - - - - - mutable-predicate - - - - -

These can't be :included, and allowing them in discrimiantors leads to
problems too:

(*string size) (since you can change the size of a string)
keyword (since you can change the package of a symbol)


- - - - - - - oddities - - - - - - 
Now, here come the ones left over:

compiled-function 	I'm reluctant to put this in with the "should be
implementation", but its out of place here.

function	"may be used only for declaration and not for discrimination"
values "this type specifier is extremely restricted"


keyword (mutable, since you can change the package)


- - - - - - - - - - - - 
Need a section "include: of classes with different metaclass". If you
include a class which has a different metaclass, the implementation of
the subclass may be completely different than the implementation of the
parent. In that case, the structure of slots isn't shared, and it may be
necessary to "copy down" any methods which refer to the parents
implementation! 
- - - - - - - - - - - - - - -

     ----- End Forwarded Messages -----