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