Fri, 18 Aug 2000 17:18:01 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
pisze:
> As Manuel already pointed out, MPTCs are not Haskell'98, and are
> very unlikely to be supported by nhc98 or hbc.
>
> But SimonM's idea of having two layers - a lower layer using H'98+FFI,
> and an upper layer using MPTC and other possible Haskell-2 features
> seems workable.
There is only a single MPTC that is a convenience wrapper at the top,
for things available elsewhere (type-driven conversion of arguments
and result). No problem of having it optionally, except of creating
the possibility of incompatible code.
Example of code that uses the MPTC:
symlink:: String -> String -> IO ()
symlink orig sym = do
call (throwIfMinus1 "symlink" symlinkC) orig sym :: IO CInt
return ()
foreign import "symlink" unsafe symlinkC :: CString -> CString -> IO CInt
Avoiding it:
symlink:: String -> String -> IO ()
symlink orig sym =
ptrToCString orig $ \origPtr ->
ptrToCString sym $ \symPtr -> do
throwIfMinus1 "symlink" symlinkC origPtr symPtr
return ()
foreign import "symlink" unsafe symlinkC :: CString -> CString -> IO CInt
I've separated the impl-dependent and impl-independent parts.
I will move the MPTC to a separately imported module.
> Well, I can see that (in principle) it is entirely reasonable to
> get rid of ForeignObj altogether, replacing it with an ordinary
> `Ptr a' and an `addFinaliser' to attach a weak pointer to it.
Except it does not work when Addr can be passed unboxed (which is
good if it does not have a finalizer)...
OCaml's runtime allows putting pointers to C memory together with
pointers to OCaml objects and immediates (as long as pointers are
even, because the 0th bit is the pointer/immediate tag). The garbage
collector distinguishes two kinds of pointers by comparing the address
with the current heap range.
So maybe it would be possible to attach finalizers to C pointers?
Doing it the OCaml's way would slow down the GC: is-in-heap check
for each followed pointer. Otherwise there could be three kinds of
fields: non-pointers (ignored), pointers to Haskell objects (followed
and finalized) and pointers to the C land (not followed but finalized).
Seems that complications would not outweight the benefits.
Pointers to C storage would have to be protected anyway when put in
a C structure or passed to a C function that calls back to Haskell.
touch would do it, but it's easy to forget if these pointers are
not distinguished as ForeignObjs/Ptrs are now. So the above taken
literally would be bad.
PS. IMHO pointers should be typed and ForeignObjs should not. The
explanation of the difference is that pointers usually point to values
marshallable in Haskell and are converted to and from these values, but
ForeignObjs usually point to opaque C structs that don't have a natural
Haskell type to describe their contents. Also ForeignObjs are used
in interfaces where they are usually newtyped anyway to be abstract.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
