Simon Marlow <[EMAIL PROTECTED]> wrote,
> > Or a simpler operation,
> > touch :: a -> IO ()
> > which does nothing but ensures that at a given place the object is
> > alive, i.e. this call cannot be optimized away early as seq could be.
> > It can be a primop that does nothing for example.
>
> Ok, that sounds reasonable. Nice in fact.
>
> readIntOfForeignObj fo i = do
> a <- foreignObjToAddr fo
> r <- readIntOfAddr a
> touch fo
> return r
>
> should expand to exactly the same code as the current readIntOffForeignObj
> primop.
>
> If you need internal pointers to a structure pointed to by a ForeignObj,
> then you'll need an arrangement of weak pointers to guarantee that the outer
> object is kept alive while the internal pointer is still in use. (actually
> the internal pointer could be a ForeignObj with a finalizer which just
> touches the outer object).
>
> Ok, so does "touch" sound like the way to go?
`touch' sounds very good to me. In fact, you might remember
that we had a discussion about basically the same issue a
while ago. (At the time when I lobbied for the inclusion of
`foreignObjToAddr'.)
In fact, having `touch', we could get rid of the condition
impossed by the last bulleted item on the page
http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-primitive.html
This condition basically requires the implicit introduction
of a `touch' by the compiler and so is redundant if we have
an explicit `touch'.
Cheers,
Manuel
