[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 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

I think that we must consider the rationales I gave in my message of 22
Jan 87 15:10 PST.  For this case the problem is:

"c) The class of any instance should be quickly determinable.  Thus
standard-char might be a case which is outlawed since it is a char that
is member of a set.  Probably bit (represented by an integer that is
either 1 or 0) also falls in this category."

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

Here the problem is whether the user is in for a surprise. 

    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

"a) all instances of the class (or any subclass) can be identified as
being of that type.  FUNCTION has a problem in that respect wrt lists. "

Perhaps we want to have methods on compiled-function.  

With these two exceptions I agree with the points expressed by Dick in:
    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.

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