On 7/20/11 1:22 PM, Chris Smith wrote:

If the latter, then it seems this would be a pretty serious garbage collector bug, and that it would be impossible that such a bug wouldn't also break other code that doesn't use pointer equality at all. After all, we've got a running user thread, which if it were to force those thunks now they would necessarily be observably equal, but if it doesn't and waits until later they may be different?

Not at all. Some amount of time passes between obtaining the pointer of x and obtaining the pointer of y in order to test whether they're equal. Given that time passes between these two steps, it's possible for GC to happen after getting one of the pointers and then when returning to user code we get the other pointer. It so happens that GC will never happen at that point on current versions of GHC, but that's not to say it couldn't (as it mustn't if the API specified no false positives). I can't think of any plausible optimization that would lead to a design which allows false positives, but I'm not sure pointer equality should really be offered in the first place. That's what StableNames are for. Pointer equality may be a reasonable implementation of StableName equality on some systems, but I really think that the two ideas should be kept separate. -- Live well, ~wren