qforeign-0.62
Simon Marlow
simonmar at microsoft.com
Tue Nov 28 09:24:04 EST 2000
> I'm with Manuel. Module FFI/Foreign is already stable, and I object
> to adding things to it arbitrarily. By all means make a new module
> with these functions, which I can see could be useful. But please
> don't just allow "feature creep" over already-agreed specifications.
Perhaps those functions which are implemented on top of the Storable
primitives should be in another module; I don't really have any
preferences. But if we move some of the derived functions out of
Storable, they should probably all be moved.
> Once these newer features are settled, I look forward to seeing a
> portable implementation.
Yes, that would be nice. In fact I think most of these features are
trivially implemented on top of Storable.
As for the errno issues, I think the hsc2hs solution is simple and
straightforward and doesn't require an architecture-dependent algebraic
datatype. BTW Maloclm, if you haven't yet taken a look at hsc2hs I urge
you to do so (fptools/ghc/utils/hsc2hs): it should work unmodified with
nhc98, and it'll let you write C constants like EINTR directly in
portable Haskell code.
Cheers,
Simon
More information about the FFI
mailing list