specializer metaobjects

[Moon@STONY-BROOK.SCRC.Symbolics.COM]

    Date: Sun, 4 Nov 1990 17:47 EST
    From:	Gregor Kiczales <Gregor@parc.xerox.COM>

    This message is a proposal to try and fix this by making EQL
    specializers themselves be metaobjects.  The general idea is to define a
    new kind of metaobject, called <specializers>.  Classes are
    specializers.  There is a new class SPECIALIZER, of which CLASS is a
    subclass.  Another new class EQL-SPECIALIZER, is a direct subclass of
    SPECIALIZER.

This seems like a reasonable proposal to me.  Perhaps it can also
help rationalize the meaning of SPECIALIZER-DIRECT-METHODS.

    In the past I have avoided doing this because I believed that 88-002R
    specifically said that the form of eql specializers (not specializer
    names) was a list of which the car was the symbol EQL etc.  I know
    believe that 88-002R doesn't say that because it doesn't have the
    conceptual framework required to do so.

Well, 88-002R indubitably contains the words "denotes a parameter specializer
as follows ... the type specifier (eql -object)".  I think we should freely
admit that this is an incompatible change to 88-002R.  The question should be,
is this an incompatible change for any programs written using only the standard
language as currently accepted by X3J13 (i.e. not using "chapter 3").
The answer is almost no; there is one thing I found in 88-002R that can be used
to tell the difference between EQL specializers as conses and EQL specializers
as metaobjects, namely FIND-METHOD's specializers argument.  Of course it could
be given a compatibility feature where conses would be accepted and translated 
to specializers, but that's probably undesirable since in practice very few or
no programs would be helped by doing that.  So I think this change should be
proposed as an incompatible change whose benefit to cost ratio is definitely
high enough to justify it, and not try to pretend that it's just a clarification.