Re: [Chicken-users] This may be a bug in chickens hash tables - or my bad

[Jörg F . Wittenberger]

Ah, great to learn.

a) You are right: Per SRFI-69 it is actually undefined.  Per chicken
manual it returns the new value associated with key.

As I've seen the latter (e.g. in the iup egg) actually being used, we
might at least want to keep the behavior in chicken.

b) But does not matter much.  I ran into this originally from
hash-table-ref signaling a missing key.

The attached, modified test case fails because it i) does not find the
key object hence hash-table-fold'ing the tree to ii) find an association
with the very key the lookup failed for before.

My hypothesis (after lightly reading the srfi-69.scm source) that the
eq?-hash procedure produces a different hash value for the lookup before
and after the mutation.  Hence the lookup fails while walking the tree
succeeds.

/Jörg

Am 16.12.2015 um 21:55 schrieb Peter Bex:
> On Wed, Dec 16, 2015 at 09:47:31PM +0100, Jörg F. Wittenberger wrote:
>> Hi,
>>
>> I always assumed that (make-hash-table eq?) would create a hash table
>> usable with arbitrary chicken objects as keys.
>>
>> That is especially structures like objects created via define-record
>> should be valid as keys.  That is: referencing the table using the very
>> same object (comparing eq? to the key object of the insert operation)
>> will succeed.
>>
>> However this fails for me.  At least after the key object was mutated
>> between insert and reference time.
>>
>> See attached test case.
>>
>> Am I trying something illegal here?
>>
>> Thanks
>>
>> /Jörg
> 
>> (use srfi-69)
>>
>> (define objtbl (make-hash-table eq?))
>>
>> (define (register! obj arg)
>>   (hash-table-update! objtbl obj identity (lambda () (list obj arg))))
>>
>> (assert (eq? (register! 1 1) (register! 1 2)))
> 
> I believe the return value of hash-table-update! is undefined.
> 
> Cheers,
> Peter
>

objtbltest.scm
Description: Text Data

signature.asc
Description: OpenPGP digital signature