That's explained in the paper. A StableName# is a pointer to a stable name object in the heap that *contains* an index into the stable name table. Basically, the garbage collector needs to know whether a stable name is alive or not, so it can work out when to clear it from the table. Very good. But could it be explained in a Note too? The paper is from a long time ago, contains lots of surrounding explanation, and might well be out of date (even if it in fact is not out of date).
So the entry in the table /also/ points to the same, heap-allocated StableName#? Doesn’t that keep it alive? Or is this akin to the treatment of weak pointers? (Which is part of the same paper.) Do we anywhere keep a pointer to the object that this is a stable name of? Simon From: David Feuer <david.fe...@gmail.com> Sent: 21 August 2018 09:25 To: Simon Peyton Jones <simo...@microsoft.com> Cc: David Feuer <da...@well-typed.com>; ghc-devs <ghc-devs@haskell.org>; marlo...@gmail.com Subject: Re: Stable name equality On Tue, Aug 21, 2018, 3:39 AM Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@microsoft.com>> wrote: Actually I'm confused. Currently we have data StableName a = StableName (StableName# a) I believe (but there is no documentation to state) that the (StableName# a) * Has kind (TYPE UnliftedRep) * Is the index of the entry in the Stable Name Table But if it's the index, why isn't it an IntRep? UnliftedRep is for pointers? That's explained in the paper. A StableName# is a pointer to a stable name object in the heap that *contains* an index into the stable name table. Basically, the garbage collector needs to know whether a stable name is alive or not, so it can work out when to clear it from the table. Moreover eqStableName# :: StableName# a -> StableName# b -> Bool is directly implemented in the code generator (StgCmmPrim) by an equality comparison. If these things are correct, it would be great to write them down in a Note. And if they are right, I'm now lost about what you question is. Equality is /already/ implemented by direct equality comparison, no? It's currently implemented by an equality test on the indices stored in the stable name objects, rather than the pointers to those objects, if I'm not very much mistaken.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs