[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re: Random metaclasses for CL types
- To: jonl@LUCID.COM, RPG@SAIL.Stanford.EDU
- Subject: re: Random metaclasses for CL types
- From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
- Date: 24 May 89 0854 PDT
- Cc: dussud@LUCID.COM, Gray@dsg.csc.ti.com, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM, common-lisp-object-system@SAIL.Stanford.EDU, chapman%aitg.dec@decwrl.dec.com
- Reply-to: <Common-Lisp-Object-System-mailer@SAIL.Stanford.EDU>
[In reply to message from jonl@lucid.com sent Wed, 24 May 89 08:03:20 PDT.]
I think the aphorism is ``the metaclass determines the representation of
instances of its instances.'' This is because MAKE-INSTANCE as a function
depends on the metaclass. So, any operation whose operation takes a class
depends on the metaclass. Representation creation is the most important or
visible of those operations. (Another use is to reify other aspects of an
object, such as the interpreter to use to execute code associated with a
class. This is sort of what Maes (1988) and Gabriel (1980) do with
metaobjects.)
Of course, there is nothing to prevent one from having MAKE-INSTANCE
select a metaclass to use that corresponds to a subclass of the original
class. MAKE-ARRAY is such a pseudo-constructor. BUILT-IN-CLASS seems to
me to be a metaclass for things that you cannot MAKE-INSTANCE of. In that
sense it might represent the metaclass for things with no metaclass at all.
I think this is consistent with what you're saying.
One reason to flush BUILT-IN-CLASS is to allow implementations to experiment
with real metaclasses for Common Lisp types. Possibly such a system would be
only of educational interest.
-rpg-