l...@gnu.org (Ludovic Courtès) writes:
> Hello!
>
> Neil Jerram <n...@ossau.uklinux.net> writes:
>
>> Just checking this because Ludovic said recently that (SCM_BOOL_F ==
>> 0) would have nice properties for BDW-GC.
>
> Actually he wasn't quite right when he said that. :-)
>
> The issue with BDW-GC is that "disappearing links" (weak pointers in
> libgc parlance) replace pointers to objects that have been reclaimed by
> NULL, and there's no way to tell it to use some other value.
>
> That leads to insanities in the weak hash table implementation [0, 1],
> which I thought could somehow vanish if SCM_BOOL_F == 0.
They're not so bad. But I agree that it would be nicer not to have to
use SCM_WEAK_PAIR_CAR, and just use SCM_CAR instead.
> Unfortunately that's not true; it would even make things worse because
> NULL would now be a valid Scheme value.
Yes, I see.
> Instead what's really needed is a special pointer-to-reclaimed-object
> value that can be distinguished from valid Scheme values since that
> value ends up in the car or cdr of weak pairs in hash table buckets. As
> such, SCM_PACK (NULL) was a good choice until now.
Here I'm confused again. I thought we now had no choice about the
pointer-to-reclaimed-object value, because BDW-GC always uses NULL.
> SCM_UNDEFINED == 0 would work fine because SCM_UNDEFINED is not a valid
> Scheme value, but it wouldn't change the implementation.
I'm afraid I don't understand "but it wouldn't change the
implementation".
0 is also used for procedures that haven't been extended to
primitive-generic - see SCM_SUBR_GENERIC - but I think making
SCM_UNDEFINED == 0 would be fine there too.
> Thoughts?
SCM_UNDEFINED == 0 is sounding promising...
Neil
