[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
disjointness of '() and #f
Date: 14 Feb 90 15:38:08 PST (Wed)
From: kend%mrloog.wr.tek.com@RELAY.CS.NET
Another factor arguing for disjointness has been raised but unstated for
some time. Disjointness [(eq? '() #f) -> #f] is much easier to explain
to students as it accords with their intuitive notions. There are areas
where Scheme differs from naive intuition for deep reasons (e.g.
exactness). It would be nice to be able to concentrate on areas where
there really are deep issues rather than areas of happenstance.
I don't understand arguments from student intuition, particularly this one.
Saying that #f marks ends of lists is just as clear as saying that
X | (null? X)
marks ends of lists. Notions like disjointness of types are less intuitive
than simple conventions like "#f marks ends of lists."
I see no problem with making disjointness of predicates BOOLEAN? and
NULL? in the IEEE Scheme Standard and allowing (e.g. Jinx) to redefine
BOOLEAN?, NULL?, LIST?, PAIR?, CONS, et cetera for idiosyncratic
purposes. As long as such *conventions* can be implemented in a standard
Scheme, there is no creative restriction and many people are saved from
needless confusion.
I would be very interested in deep reasons why such confusion should be
mandated.
Jinx, if you can explain to my simple self why you cannot redefine a
scheme implementation which follows the standard to do what you want in
this case, please do so. If not, I request that you remove your
objections.
If I assume that () and #f will be eq? in all implementations and write my code
accordingly, I'm making a mistake. I should clearly use null? to detect ends
of lists EVEN THOUGH I KNOW THAT MY IMPLEMENTATION MAKES () AND #F EQUIVALENT,
but that's no reason that () and #F shouldn't be equivalent in some
implementations (for whatever reasons). After all, if I write
(+ '(a b c) '(d e))
to append two lists knowing that my implementation of Scheme defines + on both
numbers and lists, I shouldn't expect to get the right answer on other
implementations. The language should not have to clean up after careless
programmers, after all. To say that Jinx is doing this for "idiosyncratic
purposes" is just unfriendly.