Re: truth of %nil

[Mark H Weaver]

I've been considering writing a python compiler for guile.  For python
(and others) there are several values considered to be false, such as
0 and various empty collections, and so a different approach will have
to be taken to this problem.

If we want guile to handle many different languages, should we not try
to find an approach to "false-ness" that handles many languages, and
not just a few?

It seems to me that some code might misbehave in the presence of two
values which are both null? but not eq? to each other.  Also, it seems
more consistent to use the same strategy for handling various
languages' notions of false-ness.

To my mind, we should not be changing the data (which only works for
lisp), but rather the constructs that decide whether a given value is
false.

So how about having elisp `if' and `cond' compile not to scheme `if'
and `cond', but rather to scheme `elisp-if' and `elisp-cond'?  Or
perhaps compile `(if c a b)' to `(if (elisp-true? c) a b)'.

This approach, unlike the %nil approach, will work for other languages
too.

It also means that Guile's normal `if' and `cond' won't be slowed down
by having to check for two values instead of one.  That overhead may
be insignificant now, but when we have a native code compiler, it will
be quite significant in code size at least, even if the
representations of %nil and #f differ by only one bit.

What do you think?

    Mark


On Mon, Jun 29, 2009 at 10:44:54PM +0100, Neil Jerram wrote:
> Seems wrong to me.  In Scheme #f should be the only false value.
> What's the argument for %nil being false in Scheme code?