Re: Comments on latest draft documents

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 28 Jan 88  1526 PST
    From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>

    In your message ``Comments on latest draft documents,'' you write:

    2-17 class-name: The name of a class should not be restricted in type.  The
    method signature should specialize new-value with t, the arguments should
    say new-value is typically a symbol, and the semicolon clause under
    values should be deleted.  While a class's proper name is a symbol
    unless symbol-class is somehow extended, class-name should be allowed
    to be any object.  One proposed extension we discussed earlier has
    class-name a list of classes.

    Neither Dick nor I recall this having been decided.  If this is really
    what you want, I think you should bring this up for a vote on the list.

I don't think anything was decided.  My point is that it's silly, in my
opinion, to use parameter specializers on new-value arguments to setf
methods as a way of doing type-checking (rather than specialization), and
more importantly that I don't think the CLOS specification should imply
that if you need to store a different type of value, you have to define
your own method.  I suppose this comes down to the issue of what is the
contract of the method and what is the contract of the generic function,
again.  Since we agreed not to try to solve that in chapter 2 this time
around, I would be happier if the method signatures didn't specialize
the new-value arguments.

If anyone wants to argue for or against the class-name function being
restricted by the CLOS specification to return only symbols, this is
the place to speak up about it.

    2-41 documentation method signatures: The parameter specializer name
    for new-value should be t, not string.  CLtL doesn't say anywhere what
    values are allowed, but a reasonable inference is that NIL is allowed,
    and "documentation information" might have been meant to include some
    sort of structures as well.  The allowable types here are a matter for
    CL to define, not for CLOS to legislate.

    t doesn't strike us as a reasonable generalization of string and nil.

It's the only one that CLOS has, since it doesn't allow OR.  But
my point wasn't that the specializer should be (OR STRING NULL); my point
was that it's not up to CLOS to define the allowable types here, and as
far as the CLOS specification goes, the new-value parameter should not be
restricted.

    It seems to us that adding signatures for setf methods for (eql nil)
    is a more sensible thing to do.

To me that's a much less sensible thing to do!  The need to duplicate
the method shows that using the parameter specializer to do type-checking,
rather than specialization, was a mistake.  At least that's how I see it.

I suppose none of this really matters, because it's only the method
signatures in the document, and we already agreed that those are going
to be discovered to be incorrect in the future.