I think we need to decide how the further development of the FFI will proceed. Given that Version 1.0 of the Addendum is frozen, I am not in favour of changing the Addendum anytime soon and certainly not for small matters, such as a convenience function.
We might want to accumulate extra useful functions in the implementation in an *extra* module and once there is enough interesting functionality in there, we can start talking about Version 1.1 of the Addendum.
Does this sound like a sensible approach?
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). (2) is unattractive because some of the new interfaces will morally belong in existing modules (eg. withArrayLength clearly belongs in Foreign.Marshal.Array). (3) is unattractive because the Foreign module overlaps, so we can't keep the hierarchical and non-hierarchical versions separate. (1) is unattractive because it might break code that works with the FFI 1.0 spec (unlikely, though). Cheers, Simon
I think adding new (hierarchical) modules is the way to go for now. 1) Hierarchical because it lets us use some nice clear module naming style like: Foreign.NonStd.* or Foreign.Extension.* [I favour the former since the status of the lib is clearer.] I'm a bit uncertain over how many modules should live in this new hierarchy. The easy answer is just one - by the time we have more than a module's worth of code, it's time to add some of them to the standard. An alternative is to mirror the structure of the standard libs: Foreign.NonStd.{C,ForeignPtr,Marshal,..} which would be useful if we don't want to bump the ffi version number too often. 2) I think the evolution of the ffi std from Sigbjorn's original foreign import/export proposal benefited hugely from things like the QForeign library where ideas could accumulate and become consistent, portable, etc. 3) We don't have any way to do version numbered packages at present but we need somewhere to put the code now. -- Alastair [Detail: The GHC folk might want to move Foreign.Concurrent to Foreign.NonStd.Concurrent.]
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. Cheers, S.
I wrote:
[...] 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 [...]
After some thoughts, swapping the order of the pointer and the length, i.e.: withArrayLen :: Storable a => [a] -> (Int -> Ptr a -> IO b) -> IO b withArrayLen0 :: Storable a => a -> [a] -> (Int -> Ptr a -> IO b) -> IO b might be nicer, because then we had the nice property: withArrayLen x peekArray == x Opinions? Cheers, S.
On Monday 29 Mar 2004 8:35 am, Sven Panne wrote:
I wrote:
[...] 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 [...]
After some thoughts, swapping the order of the pointer and the length, i.e.:
withArrayLen :: Storable a => [a] -> (Int -> Ptr a -> IO b) -> IO b withArrayLen0 :: Storable a => a -> [a] -> (Int -> Ptr a -> IO b) -> IO b
might be nicer, because then we had the nice property:
withArrayLen x peekArray == x
Opinions?
Well I can't forsee any circumstances where I would be likely to do that :-), but it seems sensible to be consistent about order of Int and Ptr arguments, as you suggest. Regards -- Adrian Hey
On Tue, Mar 23, 2004 at 09:04:35AM -0000, 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.
(3) seems to be working well for the H98 modules; in effect the switch to hierarchical modules has given us one-off package versioning. The only problem is that the not-so-hierarchical module Foreign is in the base package rather than haskell98, and I would argue that such an omnibus module doesn't belong in the hierarchical libraries, even if it does make your import list shorter. How about moving it?
Ross Paterson wrote:
[...] The only problem is that the not-so-hierarchical module Foreign is in the base package rather than haskell98, and I would argue that such an omnibus module doesn't belong in the hierarchical libraries, even if it does make your import list shorter. How about moving it?
Those "omnibus" modules are quite handy, the only downside of "Foreign" is that it doesn't exactly collect the modules below it in the hierarchy. This would have been the better choice IMHO, but we decided to do differently for legacy reasons, IIRC. Renaming "Foreign" will probably wreak havoc, much more than simply adding 2 functions to "Foreign.Marshal.Array", which get re-exported by "Foreign". Cheers, S.
On Tue, Mar 30, 2004 at 08:54:56AM +0200, Sven Panne wrote:
Ross Paterson wrote:
[...] The only problem is that the not-so-hierarchical module Foreign is in the base package rather than haskell98, and I would argue that such an omnibus module doesn't belong in the hierarchical libraries, even if it does make your import list shorter. How about moving it?
Those "omnibus" modules are quite handy, the only downside of "Foreign" is that it doesn't exactly collect the modules below it in the hierarchy. This would have been the better choice IMHO, but we decided to do differently for legacy reasons, IIRC. Renaming "Foreign" will probably wreak havoc, much more than simply adding 2 functions to "Foreign.Marshal.Array", which get re-exported by "Foreign".
The suggestion wasn't to rename it, but to move it from base to haskell98. Then you could add these functions without changing the interface of any of the modules listed in the FFI Addendum.
participants (5)
-
Adrian Hey -
Alastair Reid -
Ross Paterson -
Simon Marlow -
Sven Panne