[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why <empty-list> and <pair>? ...
- To: email@example.com
- Subject: Re: Why <empty-list> and <pair>? ...
- From: firstname.lastname@example.org
- Date: Tue, 01 Dec 92 12:55:56 EST
- Posted-date: Tue, 01 Dec 92 12:55:56 EST
Jonathan Bachrach (Jonathan.Bachrach%ircam.FR@princeton.edu) writes:
All this talk of the lack of a need for <true> and <false> classes
has made me wonder why it is necessary to have an <empty-list>
class. Why can't people just use `(singleton '())'?
Well, <EMPTY-LIST> and (SINGLETON '()) ARE interchangeable when used
as specializers, but I think it's worth noting that they're NOT the
same thing. There are many operations in Dylan that require a class
as an argument, not just a specializer, e.g. INSTANCE?, AS, SUBCLASS?,
etc. In CommonLisp, I often find it convenient to use the class NULL,
rather than the type-specifier (EQL '()), those being the analogues of
<EMPTY-LIST> and (SINGLETON '()) in Dylan.
Which is not to say that <EMPTY-LIST>, and to a lesser degree <PAIR>,
don't have their problems. For instance, are they instantiable? The
collection class heterarchy diagram seems to indicate that they are,
although they're not listed in the section "The Instantiable
Collection Classes". If they ARE instantiable, I should be able to do
(MAKE <EMPTY-LIST> SIZE: 5 FILL: #F)
(MAKE <PAIR> SIZE: 5 FILL: #F)
The first is obviously problematic. But if <EMPTY-LIST> and <PAIR>
are NOT instantiable, it seems a rather odd situation, since usually
abstract classes are ABOVE instantiable classes in the heterarchy.
BTW, exactly what is the denotation of "abstract class"? The
"Language Overview" section says MAKE cannot be called on an abstract
class, but that's obviously not true, as page 51 says when it explains
why MAKE need not return a direct instance of its argument class.
Does "abstract class" simply mean there are no direct instances? Then
<EMPTY-LIST> and <PAIR> are clearly not abstract, and thus I presume
(perhaps rashly) that they ARE instantiable.
Which still doesn't mean I can call MAKE on them without getting an
error. Maybe the examples above ought simply to have undefined
results, and an implementation can signal an error, or return the
(MAKE <EMPTY-LIST> SIZE: 5 FILL: #F) => '()
(MAKE <PAIR> SIZE: 5 FILL: #F) == (MAKE <LIST> SIZE: 5 FILL: #F)