RE: architecture-dependent types
Should not Foreign.C.Types, Foreign.C.TypesISO and System.Posix.Types export their types opaquely? That would make their interface and documentation architecture-independent.
The FFI doesn't explicitly specify whether these types should be exported abstractly or not, but it does say in section 6.2: "... all types exported by \code{CTypes} are represented as type synonyms or \code{newtype}s of basic foreign types ..." we should really decide one way or the other, since this ambiguity will lead to non-portable differences between implementations of CTypes (and hence Foreign.C.Types). Having the types be opaque sounds reasonable to me, and similarly for System.Posix.Types. Cheers, Simon
"Simon Marlow"
Should not Foreign.C.Types, Foreign.C.TypesISO and System.Posix.Types export their types opaquely? That would make their interface and documentation architecture-independent.
The FFI doesn't explicitly specify whether these types should be exported abstractly or not, but it does say in section 6.2:
"... all types exported by \code{CTypes} are represented as type synonyms or \code{newtype}s of basic foreign types ..."
we should really decide one way or the other, since this ambiguity will lead to non-portable differences between implementations of CTypes (and hence Foreign.C.Types).
I wouldn't mind changing this to say that they must be exported as abstract newtypes. I think when we wrote the quoted sentence, that feature that newtypes can be directly passed to foreign functions was still new, which may have contributed to the vague statement. I'll change this if there are no objections. Cheers, Manuel
participants (2)
-
Manuel M T Chakravarty -
Simon Marlow