On Aug 30, 2009, at 07:13, Neil Jerram wrote:
Mark H Weaver <m...@netris.org> 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