Re: Fwd: [srfi-126] Draft #2. (#1) Takashi Kato (10 Sep 2015 09:11 UTC)
|
Re: Fwd: [srfi-126] Draft #2. (#1)
taylanbayirli@xxxxxx
(10 Sep 2015 12:43 UTC)
|
Re: Fwd: [srfi-126] Draft #2. (#1)
John Cowan
(10 Sep 2015 13:25 UTC)
|
Re: Fwd: [srfi-126] Draft #2. (#1)
Takashi Kato
(10 Sep 2015 19:29 UTC)
|
Re: Fwd: [srfi-126] Draft #2. (#1)
taylanbayirli@xxxxxx
(10 Sep 2015 20:03 UTC)
|
Re: Fwd: [srfi-126] Draft #2. (#1)
John Cowan
(10 Sep 2015 21:10 UTC)
|
Re: Fwd: [srfi-126] Draft #2. (#1)
John Cowan
(10 Sep 2015 20:21 UTC)
|
Re: Fwd: [srfi-126] Draft #2. (#1) Takashi Kato 10 Sep 2015 09:11 UTC
Couple of questions and suggestions: Questions: - Calling hashtable-copy with weak hashtable. How should this behave when GC is invoked? Should both hashtables keys/values which are not referred any place other than these tables be collected? - Also hashtable-copy. How should hashtables copied with different weakness behave? For example, source weak hashtable A has weakness key and value, and copied one B has only value, then when one of the keys of A is GCed should B hold the key and associated value or the key should not be GCed in first place? Suggestions: - hashtable-lookup: it would be convenient to have default value which can be returned when the key is not found. (Then almost no difference between hashtable-ref, though.) - hashtable-intern!: it would be convenient that default-proc takes the key as its argument so that users can derive values from the key. - hashtable-for-each and hashtable-map!: what's the returning value of these procedures? Given hashtable or an unspecified value? - I think it would be convenient to have hashtable-map which almost the same as hashtable-map! but returns newly created hashtable. The type of returning hashtable can be in sense of hashtable-copy. So simple implementation would be the following: (define (hashtable-map proc hashtable) (let ((r (hashtable-copy hashtable #t))) (hashtable-map! proc r) r)) Cheers, _/_/ Takashi Kato Email: xxxxxx@ymail.com