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.
Cheers, S.
_______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
