John Cowan <xxxxxx@mercury.ccil.org> writes:

> Taylan Ulrich Bayırlı/Kammer scripsit:
>
>> (As far as I know, eq? is ill-defined on characters as well as numbers
>> because characters too sometimes end up being non-immediate.  Anyway,
>> whether characters fall in the same category doesn't matter much.)
>
> That's why I didn't bring them up in my previous message.
>
>> Thing is, we have no proof that the programmer doesn't care about a
>> certain number anymore (or character, symbol, ...).
>
> Again, what's the point of non-strong hashtables except to allow the
> reclamation of storage?  You haven't addressed this question.

Well, it allows reclamation of objects that are truly unreachable from
outside the hash table.

But anyway, I'm leaning towards making these semantics optional.  I'm
not sure if any implementation other than MIT/GNU Scheme supports them,
and they're probably nontrivial to implement.  Even Racket doesn't hold
on to bignums in weak tables.  Guile doesn't even hold on to floats.

The new prose would be:

    Booleans, characters, numbers, symbols, and the empty list are
    encouraged, but not required, to never be stored weakly or
    ephemerally.

with the same rationale.

A user of an SRFI-126 implementation will have to make sure that the
semantics of the implementation is what they desire.  Otherwise they may
leak memory, or they may lose hash table associations they wanted to
keep.  The only way to be safe in portable code is not to use objects of
these types in weak tables.  (Or at the very least avoid characters and
numbers.)  This is a really annoying situation, but it reflects reality
with regard to existing weak table implementations, and I'm not sure if
there's a solution short of expecting them all to agree on one
semantics.  So for now, I additionally added the following paragraph,
for the sake of responsibility:

*Warning:* In portable code, one may neither rely on weak hashtables
keeping associations for objects of these types at absence of other
references to the object, nor may one rely on the hashtable
automatically clearing associations for objects of these types.
Furthermore, the exact types of objects to which this caveat applies
differs between implementations.  For instance, some implementations
may automatically clear associations only for big exact integers and
exact rationals, whereas other implementations may also do so for all
inexact numbers.

Kinda terrible.  Ideas welcome.

Taylan