Common Lisp Types

[Dick Gabriel <RPG@SAIL.STANFORD.EDU>]

I bring up once more the question of classes for Common Lisp types.

In particular, the current Design Rationale chapter says there are
no classes for these things:

`` - Types too specific to be useful to put methods on:  bit, keyword,
     standard-char, string-char

   - The type implies an implementation, not behavior:  bignum,
     fixnum, simple-array, simple-bit-vector, simple-string,
     simple-vector

   - Specification of the type is too vague: common, function, stream

   - This is the same as (not cons), and we are not yet dealing with
     not:  atom

   - No object can be an instance of this type: nil''

I propose that we not judge what is too specific to be useful to put methods
on. I can imagine system programmers thinking standard-char and string-char
are reasonable. I think implementation as a distinguishing characteristic
for a class is perfectly reasonable. I think we must try to treat functions
well, and that streams are necessary. I agree that NOT classes should not
be included.

So I propose that every implementation be required to provide the classes
explicitly excluded in the design rationale except for negation classes
(atom) and Common, though there may be no instances of them, and I presume
we can arrange for the metaclass to state that fact. Furthermore, I
propose that the structure of the lattice in the vicinity of
implementation-dependent types be variable, reflecting the implementation
hierarchy. For example, if an implementation has single-floats only, the
classes would be:

(defclass short-float (single-float))
(defclass long-float (single-float))
(defclass double-float (single-float))
(defclass single-float (float))

and only single-float would have instances. The other permissible 
float configurations have different topology.

For functions, I propose that the Class Function include as instances
those objects in the Lisp that are in the range of the function Function.
For many implementations this will coincide with Compiled-Function, which
would be a subclass of Function. This means that CLOS adopts the attitude
that symbols and lists that happen to represent functions are the second-class
version of functions.

I propose that the class named NIL be at the bottom of the lattice and that
it also has no instances.

			-rpg-