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 12:54 UTC

Takashi Kato <xxxxxx@ymail.com> writes:

>> ***
>>
>> Booleans, characters, numbers, symbols, and the empty list object are
>> never stored weakly or ephemerally.
>>
>> *Rationale:* Objects of these types can be recreated arbitrarily, such
>> that a new instance is equivalent (as per `eqv?`) to a previous
>> instance, even if the previous instance was deallocated and the new
>> instance allocated freshly.  Therefore objects of these types must be
>> considered alive at all times even if no references remain to them in
>> a program.
>>
>> ***
>>
>> This means that if you (hashtable-set! weak-key-table 'foo object), you
>> will keep 'object' alive until either the weak-key-table is GC'd, or you
>> clear or change the association for the symbol foo.
>
> In my understanding, R6RS didn't specify those values to be non-GCable object.
> And implementations may GC symbols (at least Sagittarius does). So it seems
> a bit too much to specify like this, at least for me.

There is no such thing as a non-GCable object in the RnRS, is there?
However there are objects, like symbols with a certain name, which can
be recreated at any point and be eqv to instances that existed prior.
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.

The implementation will GC a symbol when there are no strong references
left to it.  This aspect of SRFI-126 simply means that symbols are
referenced strongly even in weak tables.  When no references are left at
all they can still be GCd.

Does that make sense?  It's kind of tricky to explain.

Taylan