Re: standard-type-classes

[masinter.pa@Xerox.COM]

I'll try to dig out the old mail on this, as I remember going into it in
some detail in the past.

The reason for avoiding "bit" is similar to the reason for avoiding
(integer 0 1) and (integer -3 3) as "classes"... there's not much
special about one integer range over another, and arbitrary ranges give
the same problems as arbitrary types. 

The reason for avoiding "keyword" is that it is (unfortunately) a
mutable property, in that it is possible to dynamically modify the home
package of a symbol (in a way that would not, for example, invoke
class-changed.)

The reason for avoiding standard-char is that it is again not a
significant "class" distinction. While it was interesting to use the
type system to categorize those characters which were somehow standard,
it was probably incorrect, the use of standard-char-p being in the same
space (in my mind) as evenp rather than integerp.

(This isn't a really good reason. I'll work on it.)

The reason for avoiding string-char is that it is too implementation
dependent whether a given actual character is in the class. (I'm less
convinced about this one than about the others.)


About FUNCTION: I agree that it is important to clean up the FUNCTION
class in Common Lisp. However, doing so implies more global changes than
are in the scope of the Object proposal; for example, it means requiring
that class FUNCTION be disjoint from other classes (including ARRAY,
LIST, and SYMBOL), and that FUNCTIONP be changed incompatibly. 

This is thus a strategic issue: is the object proposal strong enough to
carry this cleanup of CL along with it, or should it be separated? (Or,
perhaps, the wording should be something like: when CL-cleanup votes to
clean up FUNCTION so that it is well specified, the FUNCTION class will
be part of the required hierarchy.)

I'm typing this in with no text editor so forgive my spelling,
organization.

Larry