Sven.Panne at aedion.de
Sat Mar 27 04:37:51 EST 2004
Simon Marlow wrote:
> We certainly want to be able to add new stuff to the FFI over time.
> There are several ways we might do this:
> (1) Just extend the existing interfaces (don't change semantics
> of existing functions, though).
> (2) Add new modules only (not re-exported by Foreign)
> (3) Add new stuff to the hierarchical Foreign.XXX modules, but
> not the non-hierarchical variants (and Foreign keeps the
> same interface as the FFI spec).
> (4) Wait until we have versioned packages, and have separate
> ffi-1.0 and ffi-1.1 packages.
> I like (4) the best, but we can't do that yet - we know how to, but there's
> a fair bit of work to get there. Of the other options, I'm tempted by (1). [...]
Me too. The only case where this breaks existing code is when the module is
imported as a whole (directly or via a collector module) *and* there is a
function of the same name provided by the programmer. Explicit import lists
are the more prudent and defensive way if one wants stability, anyway.
Furthermore, it would only result in an easy to fix compile time error,
semantic changes to existing functions would be a completely different and
more severe story and probably a case for (4). (2) would result in a maintenance
nightmare when the new functions are moved to their "real" home, (3) is really
bad because of the reason given by Simon, and I don't think everybody wants
to hold his breath until Simon, Ross and Malcolm (just making up names here :-)
have implemented versioned packages in the respective systems, i.e. (4).
So if nobody yells, I'll add
withArrayLen :: Storable a => [a] -> (Ptr a -> Int -> IO b) -> IO b
withArrayLen0 :: Storable a => a -> [a] -> (Ptr a -> Int -> IO b) -> IO b
The "Len" suffix is more consistent with "withCStringLen", and the "0" variant
should be added for orthogonality. I propose we don't tuple the pointer and the
length like CStringLen here, because we don't have an explicit type for arrays.
More information about the FFI