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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
