[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Unable to deliver letter

Unable to deliver letter to the following recipient:
    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 KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 866567; 31 Oct 1990 16:40:11-0500
Date: Wed, 31 Oct 1990 16:45-0500
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Defining readers and writers in DEFCLASS or with separate forms
To: Gregor Kiczales <Gregor@parc.xerox.COM>, davis@ilog.ilog.FR
cc: mop.parc@xerox.com
In-Reply-To: <90Oct31.094055pst.279@spade.parc.xerox.com>
Message-ID: <19901031214541.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Line-fold: No

    Date: Wed, 31 Oct 1990 12:40 EST
    From:	Gregor Kiczales <Gregor@parc.xerox.COM>

       Date: 	Wed, 31 Oct 1990 03:12:55 PST
       From: davis@ilog.ilog.fr
	       So what I'd like to know primarily is if you think this is a
       reasonable approach.  In particular, I'm not interested in challenging
       CLOS's decisions, just in figuring out the best way for EuLisp.

    It seems perfectly reasonable to me to have DEFREADER and DEFWRITER
    macros, and to remove the functionality from DEFCLASS of defining these.
    CLOS made one choice about the style of its UI macros, this would just
    reflect another.

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.

I disagree that adding DEFREADER and DEFWRITER to the language is
reasonable.  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.  At present in
all implementations I am familiar with (DEFMETHOD FOO ((X C))
(SLOT-VALUE X 'Y)) and (DEFCLASS C () ((Y :READER FOO))) have different
performance characteristics; for example, in the Ivory version of
Symbolics Genera the defmethod is optimized for speed while the reader
is optimized for space, so the defmethod is 25% faster by my
measurement.  In some other implementations the defmethod is slower.
However this is an artifact of implementation and not inherent in the
language.  One might reasonable expect the defmethod and the reader
to be implemented exactly the same.

    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

I certainly agree with this.

    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.