[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

   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

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
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.