Re: false, (symbol #t), etc

[willc%tekchips.CRL%tektronix.tek.com@RELAY.CS.NET]

Reply to Alan Bawden:

In terms of Alan's (define (false-test) (list (eq? '() '#f) (not '()))), my
proposal was to allow (#F #F) as well as (#T #T) and (#F #T).

Reply to Jonathan Rees:

I was aware of the representation trick that Jonathan pointed out, but in the
implementation I am maintaining it is more important that Scheme fixnums have
the same representation as integers and pointers used by the Macintosh Toolbox
in ROM.  Such is life.

Reply to Jonathan Rees and Kent Dybvig:

Type inference is a concern, but it will always be heuristic.  (You can of
course restrict to the domain of the heuristics, which is how you obtain a
statically typed language).  I think I could live with #t as the only true
value, and I might like it better.  Regardless, the existence of two false
values seems more random than having all but one value count as true, and
that intuition is backed up by the complexity of implementation, so the
problem of two false values seems more urgent.  Furthermore people seem
more confused about #f and the empty list than about #t, so non-#t true
values seem less troublesome in practice.

Reply to Morry Katz and Kent Dybvig:

The R3RS is generally silent on disjointness because we have never agreed on
what is disjoint, mainly because we wanted to "grandfather" existing
implementations of Scheme.  It would have been embarrassing to have admitted,
for example, that pairs are not required to be disjoint from numbers, so the
R3RS was deliberately written in a way that encourages readers to jump to
possibly false but reasonable conclusions about disjointness.  We expected
that implementations would take the hint and change over time so that we could
be more explicit in future reports.  As I recall, the main reason we failed to
specify disjointness was that several implementations needed time to fix
problems such as:

    1.  vectors implemented as lists
    2.  characters implemented as integers or strings
    3.  #f implemented as the empty list

These "grandfather" provisions were discussed in October 1984, and sins #2
and #3, being the most widespread, were explicitly pardoned by the RRRS and
R3RS.  I think five years is plenty of warning as well as a good round number,
so I think 1989 would be a good year to add disjointness to the report.

You should suspect my timetable, though, because it's awfully convenient
that while MacScheme currently has problems #2 and #3, I expect them to be
fixed early in 1989.  I think the best way to get these changes made is for
users of Scheme to complain about implementations that haven't made them.
Implementors are likely to choose the status quo unless users' complaints
about their current system are much more serious than the complaints
feared from users whose code will break if the system changes.

That's why a number of very smart people designed something like Common Lisp
(which broke everyone's code anyway).  Kent is right that the cost of
delaying a needed change is greater than the cost of making it.  It's like
delaying a trip to the dentist.

Reply to Morry Katz and Daniel Weise:

(Weise may have been saying this.)  I see no reason why the intensional,
implementation-dependent predicates deserve recognition as part of the
language.

Reply to John Ramsdell:

As Jonathan pointed out, the R3RS clearly prohibits the behavior you
abhor.  The language designers can't do much about implementation bugs.
I think I speak for all implementors when I say:  Please report bugs!

(While MacScheme handles your test case ok, its COND macro still
special-cases the variable t.  This was a patch installed four years ago
to ease the transition from t to #t, and I thank you for reminding me
that I forgot to take it out.  No one has ever reported it.  I'm
surprised I haven't run across it myself, since I often use t as a
variable.)

Peace,
William Clinger