[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
standard-type-classes
- To: common-lisp-object-system@SAIL.STANFORD.EDU
- Subject: standard-type-classes
- From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
- Date: 21 Jan 87 1421 PST
Referring to the design rationale chapter, there are comments about
what Common Lisp types should have classes. Some of the reasoning
for exclusion needs to be re-examined:
``Types too specific to be useful to put methods on: bit, keyword,
standard-char, string-char.''
Hm, I need more convincing than this.
``The type implies an implementation, not behavior.''
What's wrong with being able to write programs that reason about this?
If we had BUILT-IN-CLASS and STANDARD-TYPE-CLASS, we could distinguish
implementation details.
``Specification of the type is too vague.''
Included in this last case is FUNCTION. The rationale then says that
there is no function to make functions. Maybe so, but functions get made
and returned, and the user is quite aware, by design, of when it happens.
One can argue that a user might be aware of the fact that he is making
bignums, but he isn't required to be so aware. With functions you don't
start off with an array and when it becomes too complex it turns into
a function; there is nothing that gets turned into a function without
a user knowing it in the same way that a fixnun becomes a bignum.
I see no reason to further demean functions than they aleady are in
Common Lisp.
``No object can be an instance of this type: nil''
I want to call the class miasma a lattice to avoid having to
mention exceptions everywhere. A class with no instances is
reasonable for this. Also, Larry Masinter pointed out that
this could be a way to solve the unsupplied optionals problem.
An unsupplied optional ``matches'' a parameter specifier that
of this class. Maybe we don't want to call it NIL, but it's
the logical name for it.
I don't like the heuristic of only admitting types that have
makers or no single function that is a maker, because the
user simply wants to reason about the things that are, not
the things that came into being by some particular mode.
If it's bad to reason about the implementation technique, it's
almost as bad to reason about the history of a thing.
-rpg-