Defining readers and writers in DEFCLASS or with separate forms

[davis@ilog.ilog.fr]

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