[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re: Random metaclasses for CL types
- To: Gray@dsg.csc.ti.com, RPG@SAIL.Stanford.EDU
- Subject: re: Random metaclasses for CL types
- From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
- Date: 24 May 89 1901 PDT
- Cc: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, dussud@LUCID.COM, jonl@LUCID.COM, common-lisp-object-system@SAIL.Stanford.EDU
- Reply-to: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
[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
methods.''
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
(TYPEP (FIND-CLASS 'READTABLE) 'BUILT-IN-CLASS)
returns T.
Are you thinking of a portable programming environment?
-rpg-