[Top][All Lists]

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

Re: truth of %nil

From: Ken Raeburn
Subject: Re: truth of %nil
Date: Sun, 30 Aug 2009 18:01:48 -0400

On Aug 30, 2009, at 07:13, Neil Jerram wrote:
Mark H Weaver <address@hidden> writes:
This numbering has the nice properties that 0 is #f.
Just to be clear: will this mean that (SCM_BOOL_F == 0) ?  As things
stand I don't think it will, because SCM_MAKIFLAG shifts and adds

Just checking this because Ludovic said recently that (SCM_BOOL_F ==
0) would have nice properties for BDW-GC.

Was that in list email? Maybe I overlooked it. Having all-bits-zero be a valid object would make some things easier in my guile-emacs work too, but could cause other problems as well. In Emacs all-bits-zero is now integer-zero, and in some places Lisp_Object variables are used or made visible to GC before being explicitly set, so I have to set them. In guile-emacs, I can check in key places (like 'cons', or the 'EQ' macro) for all-bits-zero and flag an error, or in certain cases patch over the problem temporarily. While the integration is still minimal, I suppose SCM_BOOL_F shouldn't be showing up in elisp processing, so that still works, but if it gets moved further along as I'm hoping, that could change. Having the default C initializer change from one valid value to another between Emacs and Guile-Emacs could make the bugs much more subtle.

I kind of assumed that making all-bits-zero an invalid value was a conscious choice by the Guile (or SCM?) designers which wasn't likely to be revisited. It is, after all, a fairly easy way of highlighting a certain class of uninitialized-value problems -- choosing strict checking and debugging over letting the programmer be lazy.

I think I'm mildly in favor of keeping all-bits-zero as an invalid representation. But, if it's a huge win for BDW-GC, maybe it's worth it.


reply via email to

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