Email list hosting service & mailing list manager

Weakness of "non-object" types taylanbayirli@xxxxxx (04 Dec 2015 10:51 UTC)
Re: Weakness of "non-object" types Takashi Kato (04 Dec 2015 12:28 UTC)
Re: Weakness of "non-object" types taylanbayirli@xxxxxx (04 Dec 2015 12:54 UTC)
Re: Weakness of "non-object" types Takashi Kato (04 Dec 2015 14:27 UTC)
Re: Weakness of "non-object" types taylanbayirli@xxxxxx (04 Dec 2015 16:51 UTC)
Re: Weakness of "non-object" types John Cowan (04 Dec 2015 15:12 UTC)
Re: Weakness of "non-object" types taylanbayirli@xxxxxx (04 Dec 2015 16:41 UTC)
Re: Weakness of "non-object" types John Cowan (05 Dec 2015 07:15 UTC)
Re: Weakness of "non-object" types taylanbayirli@xxxxxx (05 Dec 2015 12:50 UTC)
Re: Weakness of "non-object" types John Cowan (06 Dec 2015 04:41 UTC)
Re: Weakness of "non-object" types taylanbayirli@xxxxxx (06 Dec 2015 10:21 UTC)

Re: Weakness of "non-object" types taylanbayirli@xxxxxx 04 Dec 2015 16:51 UTC

Takashi Kato <xxxxxx@ymail.com> writes:

>> So from the programmer's perspective, the object never disappears; a new
>> reference to it can be created any time, even if its memory address
>> changed, so it would be strange for a hash table to drop an association
>> for that object.
> I understand the purpose and indeed it might look weird to programmers if
> they don't know how the memory management of the implementation works.
> However, IMO, weak hashtable shouldn't hold implicit strong reference if
> it's specified to hold as weak reference by users. One of my expected
> behaviour is the following (suppose symbols are GCable)
>
> ;; suppose nobody holds symbol 'foo
> (define wh (make-eq-hashtable 16 (weakness weak-key)))
> (hashtable-set! wh (string->symbol "foo") #t)
> ;; do something causes GC.
> ;; (gc)
> (hashtable-ref wh (string->symbol "foo") 'gone)
> ;; -> gone (if symbol 'foo is already GCed)
>
> If users want to make sure the symbol 'foo is kept after GC, then they should
> make other storage to store it. I think it's more consistent and clearer than
> introducing implicit strong reference semantics.

Please see my reply to John for the rationale behind referencing
symbols, characters, and numbers strongly in weak tables.

But I'm yet undecided whether I'll keep these semantics.

Thanks for your input,
Taylan