Re: Amendments requiring additional writing

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

    Date: 26 Sep 87 16:40 PDT
    From: Masinter.pa@Xerox.COM

    While fixing typep and subtypep to deal with classes seems likely to
    preferable to adding instancep and subclassp, attempting to fix type-of
    so that it sometimes returns a class and sometimes returns a symbol
    seems hopeless, and bad design. type-of is so underconstrained in any
    case to be worthless. I think you're better off abandoning it -- e.g.,
    implementations can return T if on instances of classes if they need to.

That isn't what we decided to do when we discussed type-of earlier.

The basic principal here is that class objects are legitimate
type-specifiers, they are just not quite as nice to read as symbols.
The fact that there is more than one type-specifier that refers to
exactly the same set of objects is not new to Common Lisp.
Thus making type-of return a class object when there is no meaningful
symbol to return doesn't strike me as making the design of type-of any
worse than it already is.  I would be favorable towards a proposal to
remove type-of from Common Lisp entirely, but not towards one to leave
type-of in Common Lisp but declare it broken for CLOS-defined objects.

Aside: this reminds me of an interesting infinite regress.  Suppose the
printed representation of an object is #< ... > enclosing the printed
representation of the object's type-of followed by something to try to
distinguish different instances of the type.  Now suppose the object's
type is an anonymous class, and the class's type is an anonymous metaclass,
and the metaclass's type is itself.  If something special isn't done,
the printed representation starts with an infinite sequence of #< brackets.
Of course this kind of problem is not new, and is easily solved in an
ad hoc way.

    The proponents for disallowing careless name->value mappings will likely
    be unhappy with the polymorphic typep and subtypep; it might be useful
    to be able to lexically determine whether they might be used in a given
    program. 

That's a good point.  Of course it's impossible to determine this lexically
if the relevant functions are used with non-constant arguments, at least if
the data flow and control structure are sufficiently complicated that the
program cannot be statically fully analyzed.

I see two responses to this: the radical response is, this shows how the
type system in Common Lisp is misdesigned, because types are not
first-class objects of their own type.  Let's rip out the entire type
system and replace it with a whole new one that's better designed.  The
conservative response is, this shows how the type system in Common Lisp
is misdesigned, but let's not rip everything apart now.  Instead let's
figure out how to fit a better type system (CLOS) into the existing
language in a smooth way.

At this point I always go for the conservative approach.  If I was designing
a new dialect of Lisp, I wouldn't be doing it in the CL-Cleanup committee.

    Does anyone else see a linkage between the function-type proposal and
    the form for typep/instancep subtypep/subclassp type-of/class-of?

Not me.  Do you see a deeper linkage than the one you mentioned, that is
another case of names and referents being allowed to be used interchangeably?