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