guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: truth of %nil


From: Mark H Weaver
Subject: Re: truth of %nil
Date: Fri, 3 Jul 2009 11:32:22 -0400

Thank you, Neil, for the pointers to earlier discussions of this
subject.  Having read them, I've been convinced that the %nil approach
is reasonable and probably the best way to deal with elisp<->scheme
interoperability.  Though, like you, I was not willing to easily
accept two false values and two end-of-list values :)

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

I'll answer this in a later email.

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

A single compare and branch is a very short instruction sequence,
especially (on some architectures at least) if the constant being
compared is a small number.

When there are two values to compare against, that means either two
compares and two conditional branches, or, if the two values differ by
only one bit, ANDing with a mask before the compare.  Either way, the
code size increases quite a bit.  This price will be paid for every
boolean test, and every end-of-list test, which are obviously very
common.

It might be worth considering a build-time option to disable %nil, so
that it's possible to build a version of guile which doesn't pay this
price.

   Best,
    Mark




reply via email to

[Prev in Thread] Current Thread [Next in Thread]