Mon, 11 Dec 2000 02:03:27 -0800, Simon Marlow <[EMAIL PROTECTED]> pisze:
> Change to the FFI recently discussed on the mailing list.
> Still to come: error handling utilites.
>
> This is mostly untested.
Thanks. I've been sceptic about ForeignPtr, but now I like it.
In three of qforeign's library interfaces it is applied only to type
tags, but it caused a small simplification: no newtype constructor
wrapping and unwrapping. Ptr () in foreign imports changed into
Ptr TheAppropriateTypeTag, which is good.
I've been worried that in practice types become non abstract (of course
one could always use newtypes, but having both a newtype and a tag is
somewhat redundant). But it's not really a problem. One requires ghc
extensions to make instances for such types, but the whole FFI is an
extension anyway. OTOH when a different (==) than pointer equality
is needed, the type must still be wrapped in newtype.
In the fourth case, Libgr, it was a real improvement which convinced
me that ForeignPtr was a good idea. Parametrized newtyped ForeignObjs
used in overloaded functions, which required using pattern and result
type signatures to pass the type from the parameter of the newtype
to pointers extracted from the ForeignObj, changed into ForeignPtr
applied to real storable types. All types magically began fitting.
It is similar to the case of character encoding conversions, where I
originally wanted them to have a single type but distinguishing streams
of Chars from streams of Bytes caused surprising simplifications. I
learned that types acting as tags for parametrizing other types are
really nice, and Haskell likes to be statically typed!
If only it was not necessary to introduce value constructors in
definitions of type tags...
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
