[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Defining readers and writers in DEFCLASS or with separate forms
- To: Moon@stony-brook.scrc.symbolics.COM
- Subject: Defining readers and writers in DEFCLASS or with separate forms
- From: davis@ilog.ilog.fr
- Date: Thu, 1 Nov 1990 10:31:12 PST
- Cc: gregor@parc.xerox.com, mop.parc@xerox.com, davis@barbes.ilog.fr
- In-reply-to: "David A. Moon's message of Wed, 31 Oct 1990 16:45-0500 <19901031214541.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>"
Mopers,
I didn't realize mop@xerox had such a wide distribution. Again I
reiterate that I'm considering these questions in the light of EuLisp.
I apologize to those reading who haven't had a chance to read the
current version of the EuLisp definition. I can mail Latex sources of
this (evolving) document to those who are interested. You should be
very interested, because it is quite long and rather complicated to
produce from what I can give you.
I agree that it would have been a reasonable choice to remove readers
and writers from DEFCLASS and do them separately. CLOS chose to include
an abbreviation for this common programming cliche.
In the current EuLisp definition, DEFCLASS and DEFSTRUCT are
considered shorthand for a (potential) MAKE-INSTANCE + global binding
+ declaration and the accessor defining operations.
I disagree that adding DEFREADER and DEFWRITER to the language is
reasonable.
I am not suggesting adding DEFREADER and DEFWRITER to CommonLisp.
That decision is, in any case, already made. However, here we have
this new language, EuLisp, whose object system is largely derived from
CLOS, and so I want to see how much of pure CLOS makes sense in that
context and how these other ideas might fit in.
If readers and writers are going to be defined with
separate forms, they can be defined with DEFMETHOD. There is no reason
at all that DEFMETHOD should not be adequate for this.
Even in CLOS, I don't see how the current version of DEFMETHOD can do
the equivalent of the accessor definitions. Gregor suggested that
DEFMETHOD be able to determine the class of the method metaobject
produced, and I think that would do the trick.
But, two comments. First, the reason to do so certainly isn't to help
the compiler. Unless I am missing something, the compiler should be
able to do just as well well with the CLOS form as with explicit
DEFREADER/DEFWRITER forms.
In CLOS the accessor slot options are defined to produce methods of
particular classes on generic functions of constant names. In EuLisp,
these options are guaranteed to do the same thing as equivalent
DEFREADER/DEFWRITER/DEFACCESSOR defining forms. So in this sense the
compiler can do the analysis in both languages. The point I was
trying to make, perhaps badly expressed in my original note, is that
if some defining form is going to make a definition, there should be a
way for the user to do it explicitly as well.
A related sidenote: The new MOP goes to great lengths to forbid the
metalevel programmer from overriding the behavior provided by the
STANDARD-CLASS methods for INITIALIZE-INSTANCE and SHARED-INITIALIZE.
I am not entirely sure why it was done this way instead of the
(perhaps more complicated) behavioral restrictions on what an
overriding method can do. However, there is a large area of class
initialization behavior outside the scope of those rules which can be
completely overridden. For example, if I wanted to break the rules
about what the accessor options do for a new class metaobject class
and slot definition metaobject class, it would be easy to write a
method for DIRECT-SLOT-DEFINITION-CLASS for the new class metaobject
class and then an overriding method for SHARED-INITIALIZE for the new
slot definition metaobject class. Did you mean for similar
restrictions to apply to INIATILIZE-INSTANCE/SHARED-INITIALIZE for
other metaobject classes as well?
Second, I believe that if you were really going to do this right, the
only thing you would define is the underlying functionality---the
explicit metaobject manipulation layer. None of these macros, or the UI
syntax in terms of Lispo forms would be defined.
This is fine for implementors but ignores the issue what language
programmers use to communicate with each other. It's nice to have a
standard for the surface syntax of Lisp forms so that programmers can
read each others' programs. I suppose you coudl argue that publication
should be in a machine-readable form which each reader translates to
their favorite surface syntax (using a program) before reading it.
In fact, the EuLisp definition specifies the defining forms, the
generic functions used to implement them, and the behavior of the
kernel metaobject classes for these generic functions. I think this
is what Gregor means, but perhaps I'm wrong. I agree (I think) with
Moon that it is important to define both layers, but not just for
programmer convenience, and not just because we are technologically
impoverished. The defining form layer provides explicit compiler
declarations which the underlying functions cannot since they do not
refer to names.
Thank you all again for participating in a discussion which is not
necessarily directly relevant to your work.
-- Harley