Mon, 11 Dec 2000 02:03:27 -0800, Simon Marlow <simonmar@glass.cse.ogi.edu> 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 * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK