Re: truth of %nil

[Neil Jerram]

Mark H Weaver <address@hidden> writes:

> I've been considering writing a python compiler for guile.

Great!

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

There's been loads of prior discussion on this subject.  Here are
pointers to some of that.

http://sourceware.org/ml/guile/1999-07/msg00251.html
http://sourceware.org/ml/guile/1998-07/msg00187.html
http://lists.gnu.org/archive/html/guile-devel/2001-09/msg00140.html
http://lists.gnu.org/archive/html/guile-devel/2001-11/msg00016.html

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

Example?  (This seems quite unlikely to me.)

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

Certainly this is a possible approach.  In what's been done so far,
and what we do in future, I don't think there are any arguments that
trump all the other considerations.  It's just a matter of balancing
performance, robustness, and so on.  If more non-Lisp-like languages
are added, your consideration of cross-language consistency would gain
more weight.

On a matter of detail, I don't understand your statement that the
current %nil approach won't work for other languages.  As the query
that started this thread shows, it is perfectly possible to code a new
language (VM-Scheme, in this case) in which %nil is true.

If I understand it correctly, a key point of the thinking up till now
is that Elisp is a special case because it is so `tantalizingly
similar' (as Jim put it) to Scheme.  This similarity creates the
possibility of passing data directly between Elisp and Scheme, and the
fact that Guile Scheme treats %nil as both #f and '() follows from
that; otherwise it would be necessary to convert data as it passes
from one language to the other.  In other words - a performance point.

Now we have Brainfuck and ECMAScript too, but I don't know if they are
complex enough to cast significant doubt on the existing balance.  (To
be honest, I'm not sure if that's true for ECMAScript, I need to look
at Andy's code.)

Python on the other hand would be plenty complex enough, and I assume
it has arbitrarily complex data structures.  How do you envisage data
transfer working between Python and other languages?

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

Do you really think so?  Just because of two compare operations
instead of one?  Perhaps I'm misunderstanding you.

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

(Just for the record, my statement here was wrong, and I've since
corrected it.)

Regards,
        Neil