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 Takashi Kato 04 Dec 2015 12:28 UTC
> *** > > 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. Cheers, _/_/ Takashi Kato Email: xxxxxx@ymail.com