[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on new draft chapter 1 (dated May 13 20:53)
Date: Fri, 20 May 88 17:35 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Comments on a subset of your comments, not to imply that the remainder
should be ignored. In general I agree with them.
1-25 To this reader, the statement in the 4th enumerated PP that ``The
checking of the validity of keyword names is done in the generic
function, not in each method'' seems inconsistent with the second PP on
1-26 ``If a method is passed a keyword argument is does not accept, an
error is signaled.'' Is the indent to draw some distinction between &key
args from DEFGENERIC and those which come from random DEFMETHODs? If
so, this should be made a lot clearer.
I missed this one in my recent review of the document.
I believe the word "method" in the 2nd pp on 1-26 is a typo and should
be "generic function." Clearer would be "If a generic function is passed
a keyword argument that no applicable method accepts, an error is signaled."
Also, for consistency with the last paragraph on CLtL p.62, it should be
"an error should be signaled" rather than "an error is signaled." Not
that I am a fan of implementations that allow you to turn off error checking.
I don't follow.
1-33 Penultimate PP. I am probably just plain confused on this point,
but is it possible that ``and instances of the classes standard-method,
...'' should read just ``the classes standard-method, ...''? The
reference to standard-method in the following bulleted PP reinforces my
No, the text is correct as it stands. Everything involving meta objects is
inherently confusing because it's difficult to keep the two levels straight.
1-39 3rd PP. I question the use of the word ``captured'' (which occurs
in other places in both Chapters 1 and 2.) ``Inherited'' seems more
straight-forward to me. This is probably just a personal preference.
"Captured" refers to lexical capturing, not class inheritance. I'm not
sure it's necessary to repeat "captured" periodically; we could just leave
it to the explanation on 1-10 and again on 1-35.
1-39 Table. The last line would seem to imply that the defaulted
initlist must always be '(a 1 a 2 b 2), ruling out the `optimization'
(a 1 b 2). Is this the intent? It seems to unnecessarily constrain the
behaviour of default-initargs methods.
"a 2" was not put in by defaulting, it was supplied explicitly by the caller.
Given that, I don't think we want to change the table.
1-39 The section `Shared-Initialize' The introduction of this section at
this point seems very unmotivated. Nowhere above (except by implication
of the `--'-bulleted PPs on 1-37) is it made clear that
shared-initialize is an `underlying' method called by all the various
(re)initialization methods. Some small preamble at the beginning of
this section would make a first-time reading of the the spec somewhat
The spec is deliberately made difficult to read to discourage people from
making implementations without reading it slowly and carefully :-)
At this point I suppose I might as well express my misgivings about
the name `shared-initialize' -- it seems to imply to me something to do
with `shared' (ie class-allocated) slots or something like that. For
what it's worth, I'll state that the names `initialize-slots,'
`basic-initialize' and even `common-initialize' (or even
`initialize'!) appeal to me more than `shared-initialize.'
The false connotation of shared slots is the same comment I had. However,
all four of your suggested alternatives have problems, and we spent so much
time trying to find a better name that I think we should go with the one
we have for this round of the document, and let X3J13 instruct us to change
it if they so desire.
1-40 First (bulleted) PP. What if the instance doesn't have a slot with
named by one of the elements of the list? Is it ``an error?'' Is
You're right, we need to specify this. Let's make it "the results are
1-41 Definition of make-instance. Is nobody else bothered by the fact
that the use DEFAULT-INITARGS may be a consful operation in the presence
of :default-initargs? It would be very easy for the evaluation of
DEFAULT-INITARGS to consume more storage (to construct a merged initargs
list) than that of ALLOCATE-INSTANCE does in creation of the instance
Of course. But the spec defines the semantics of the language, not how
to do semantics-preserving implementation-dependent optimizations. I
don't think complicating the specification to make it slightly more
obvious how to optimizations is a good tradeoff. Also, with reasonable
garbage collectors, which are starting to emerge even on traditional
hardware, consing is not such a burden.
Finally, just to be contentious (I'm not inviting replies):
Yes, CLOS definitely has that design-by-committee aroma.
* I find the `evalness' of define-method-combination very disturbing.
It seems to me that a full lisp compiler or evaluator will need to be
present in any world into are loaded methods on generic functions which
use user-defined method-combination. I would -very- much like to be
convinced that this isn't the case.
I don't understand your point. How is define-method-combination different
from defmacro in this respect? Perhaps you've been misled by the way the
spec describes everything as if it was interpreted into thinking that it
cannot be compiled?