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)
|
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