Re: truth of %nil

[Ken Raeburn]

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

Ken