false

[Jonathan A Rees <JAR@AI.AI.MIT.EDU>]

I support this change.  However:

    Date: 10 Mar 88 14:39:25 PST (Thu)
    From: willc%tekchips.CRL%tektronix.tek.com at RELAY.CS.NET

    One of the things that discourages implementors from making
    the empty list distinct from #f is the fact that the empty
    list counts as false.  On many architectures this makes it
    slower to test a boolean value (unless the implementor
    biases the representations to take this problem into account,
    which would probably make other operations slower).  In
    MacScheme, for example, testing a boolean return value
    currently looks like

            cmp.l   #F,RESULT
            beq     ---

    but would look like

            cmp.l   #NULL,RESULT
            beq     ---
            cmp.l   #F,RESULT
            beq     ---

    if #f were different from the empty list.

Unless I'm overlooking some vagaries of the way byte and word
instructions work on the 680x0, then I think you can do better than
this, if you can arrange that the low N bits (for N = 8 or 16) of #f and
() are the same, and different from the low N bits of every other
object.  Then the false test becomes

	cmp.w    #NO,RESULT   ;Or cmb.b
	beq	 ---

where NO is the distinctive false bit pattern.

On the 680x0, if RESULT is not a register, then an offset of 2 or 3 must
be added to the effective address.  On the little-endian VAX the right thing
happens automatically.

"Always looking for better kludges to promote inelegance."

And another nit:

    Having the empty list count as false makes it harder to do
    type inference, because for example you can't tell whether
    a procedure that returns the empty list is supposed to return
    a boolean or a list.

If type inference is a concern, then it seems to me that accepting, say,
the symbol T as a true value is just as much of a problem as accepting
the empty list as a false one; in either case you are going to have
trouble deducing that something is a boolean.  Seems to me that the only
way to make type inference work well is to not only separate () from #f,
but make it be an error to allow anything other than a boolean as the
value of a test in an IF.  I suspect this position would be too radical
to be accepted by most of us, perhaps even including me.

In spite of these objections: as stated above, I support making the
trueness or falseness of () be unspecified.