RE: Accessing ForeignObj contents from Haskell

[Simon Marlow]

> Having cheap touch (and thus hold), it's easy to make all 
> peek variants
> safe themselves. Remove hold here. Only the above operations need
> care. The programmer has to ensure that values with finalizers are
> alive during use of values based on them in the above sense.
> 
> ForeignObjs are unnecessary! Long live addFinalizer!

Um, there's a problem with addFinalizer.  Consider:

        let a = A# (intToAddr# 0x800000#) in
        addFinalizer a (free a)
        return a

the compiler could transform this into

        let a = intToAddr# 0x800000# in
        addFinalizer (A# a) (free (A# a))
        return (A# a)

(which it might do as part of worker-wrappering the enclosing function).
Now the finalizer is on the wrong object, and will run too early.

This is a problem we've known about for a while, and it's one reason we have
ForeignObj: because they're atomic heap objects and therefore don't suffer
from transformational bogosity.  It's also the reason we have a special
addForeignFinalizer rather than calling addFinalizer on the ForeignObj, and
it's the reason we have IORef.mkWeakIORef.

The problem is that the object a has no identity; the compiler is free to
duplicate it.  A few fixes for this problem have been suggested, but nothing
nice (or robust) so far.

Cheers,
        Simon

PS. why are we talking in 10pt Arial?