Unable to deliver letter

[Postmaster@JASPER.SCRC.Symbolics.COM]

Unable to deliver letter to the following recipient:
  mop.PARC@xerox.com:
    After trying without success for 1 week to contact the relevant
    domain servers needed to resolve the domain name "xerox.com",
    the Mailer must presume that there probably is no such domain.

----- Text of letter follows -----
Received: from SEAR.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via INTERNET with SMTP id 410632; 5 Nov 1990 10:38:10-0500
Date: Mon, 5 Nov 1990 10:39-0500
From: Scott Cyphers <Cyphers@JASPER.SCRC.Symbolics.COM>
Subject: specializer metaobjects
To: Gregor@parc.xerox.COM, mop.PARC@xerox.com
In-Reply-To: <90Nov4.144757pst.284@spade.parc.xerox.com>
Message-ID: <19901105153931.4.CYPHERS@SEAR.SCRC.Symbolics.COM>

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

I think this is a step in the right direction.

    The tricky point is in describing the conversion of the external format
    of specializers (what appears in DEFMETHOD forms) to specializer
    metaobjects.  This conversion needs to be based on a notion of
    `interning'.  

Is there any reason for this other than to conserve space?  If it's just
to preserve space, this seems like a job for the implementation, which
may have access to things like weak tables to help it do the job.  Just
make the MOP say "An implementation is free to share specializers that
behave the same" or something like that.
		  
		  That is two external forms which both describe the `same'
    specializer should in fact produce the same specializer metaobject.  The
    definition of `same' depends on the specializer in question.  For
    classes, the interning function is just FIND-CLASS.  For EQL
    specializers, the interning predicate is EQL. And so on.

We already preserce initforms for slots, why not specializer forms for
specializers?  For example, if *FOO* and *BAR* are EQL, then (EQL *FOO*)
and (EQL *BAR*) do the same thing, but look different.  For an
implementation which saves initforms, saving the specializer form makes
just as much sense.

    Here is some naive model implementation code:

    (defclass class (specializer) ..)

You call yourself an MOP programmer?!  There should be a specializer
class, with subclasses class-specializer and eql-specializer.
Specializer takes an initarg :SPECIALIZER-FORM.  Class-specializer also
takes :CLASS and eql-specializer takes :OBJECT (or or some better name).

I'd like to see a parse-specializer generic function (two arguments, the
form and the environment) and a parse-cons-specializer, three arguments,
the car of the form, the cdr of the form, and the environment.  I'm not
sure if the environment is really needed; better safe than sorry.  CLOS
would come with two methods for parse-specializer, one specialized on
symbol and one on cons.  parse-cons-specializer would have one method,
eql-specialized on EQL.  Our CLIM would also add one eql-specialized on
CLASS which provides an alternative syntax for a class specializer.