Newtype unwrapping in the FFI
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Thu Feb 12 18:49:23 EST 2009
Simon Peyton-Jones:
> | > * Clarify the spec to say that a newtype can only be
> automatically
> | > unwrapped if the newtype constructor (MkN in this case) is in
> | > scope
> |
> | I agree up to here. For user-defined types, not exporting the
> | constructor should be a guarantee of abstraction.
I also don't really see an alternative. The ability to pass a type to
a foreign function tells us something about the type; there is not
much we can do about that.
> | > It happens that a large set of types from Foreign.C.Types, such as
> | > CInt and friends, are exported without their constructors, so
> adopting
> | > this new rule would require us to change Foreign.C.Types to
> expose the
> | > representation of CInt and friends. (As it happens, nhc
> requires this
> | > already, so there's some #ifdeffery there already.)
> |
> | The thing about CInt though is that it is supposed to be abstract
> *and*
> | an FFI type. I want to think of it as a primitive FFI type (though
> it is
> | not a "basic" type as defined by the FFI). We don't want to know
> that on
> | some system it is Int32 and on others it is Int64. We do not want
> access
> | to the constructor here.
>
> Trouble is, there are a zillion types in Foreign.C.Types, and
> another zillion in Foreign.Posix.Types. Do you want to list them all
> as "blessed" in the FFI addendum?
The types in Foreign.C.Types are already listed in the FFI addendum
(it actually specifies the whole module, just like the report
specifies what is in the Prelude).
However, I think an argument can be made that hiding the
implementation of the types in C.Foreign.Types is a Bad Thing. FFI
code is inherently architecture dependent due to the varying sizes and
representations of C types. Hiding that variation behind a newtype
serves only to obscure that dependency, it certainly doesn't resolve
it. I know that Section 6.2 of the FFI addendum requires these
exports to be abstract, but I now tend to think that this was a mistake.
Manuel
More information about the Haskell-prime
mailing list