Wed, 16 Aug 2000 02:29:58 -0700, Simon Marlow <[EMAIL PROTECTED]> pisze:
> Well, there's readXXXOffForeignObj and friends.
It would lead to duplication of code. Suppose the C struct under a
ForeignObj contains an array of char (not a pointer), Then to use
a generic function walking the array, the address of its beginning
would have to be converted to Addr / Ptr, which cannot be easily done
safely. To keep the ForeignObj alive, all accesses have to take place
through the whole ForeignObj and offsets computed from its beginning.
> > Maybe there should be an operation that prevents an object from
> > being freed for some time, as if using StablePtr, with an interface
> > similar to
> > hold :: a -> IO b -> IO b
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.
Both of these operations can define the other one.
I was wrong that they require sophisticated analysis how to do it
cheaply. It should be very simple.
> You could certainly do this, but I'm not sure how it would help.
They allow writing a safe
foreignObjToAddr :: (Addr -> IO a) -> ForeignObj -> IO a
foreignObjToPtr :: (Ptr x -> IO a) -> ForeignObj -> IO a
or a generic
peekFO :: Storable a => ForeignObj -> IO a
implemented in terms of peek.
The above touch is a generic solution to things like this. Libraries
could even use pointers instead of ForeignObj. ForeignObj only gives
protection to a C function that calls back to Haskell. More protection
is needed anyway in some other cases, like putting it in a C array
or pointer operations on its contents done from Haskell.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
