[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
false
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.