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

re: Random metaclasses for CL types

[In reply to message from Gray@DSG.csc.ti.com sent Wed, 24 May 89 16:22:32 CDT.]

I actually made a mistake. I meant to also delete the requirement of the
existence of BUILT-IN-CLASS as well, but not the concept of built-in
class.  However, I'm not certain that this is the right way to address
what I think is the real concern, which is that it's possibly the
restrictions on built-in classes that we might wish to loosen. In the
following paragraph we state that errors are signaled:

``A built-in class is one whose instances have restricted capabilities or
special representations.  Attempting to use {\bf defclass} to define 
subclasses of a built-in class signals an error.  Calling {\bf
make-instance} to create an instance of a built-in class signals an error.
Calling {\bf slot-value} on an instance of a built-in class signals an
error.  Redefining a built-in class or using {\bf change-class} to change
the class of an instance to or from a built-in class signals an error.
However, built-in classes can be used as parameter specializers in

I think the real concern is that some implementations might wish to allow
even the holy types to respond to these protocols. I think we don't want
to prevent it. Maybe this is a point at which we wish to consider such
things as ``implementations are free to extend the \OS\ to allow {\bf
defclass} to define subclasses of a built-in class,'' and the same
for the other protocols.

In trying to translate Moon's proposal into something I can more
easily understand, I came up with this; is it a fair copy?

  Each class that corresponds to a predefined Common Lisp type specifier
  can be implemented in one of four ways, at the discretion of each
  implementation.  It can be a {\bit standard class\/} (of the kind
  defined by {\bf defclass}), a {\bit structure class\/} (defined
  by {\bf defstruct}), a {\bit built-in class\/} (implemented in
  a special, non-extensible way), or any other implementation-defined
  class that allows it to be used as a parameter specializer in a method.

In Gray's example of the use of BUILT-IN-CLASS, I can't imagine that someone
writing a portable program couldn't devise a more portable solution to the
problem, especially if there is alternative that is used if the


returns T.

Are you thinking of a portable programming environment?