Hello, The FFI currently provides.. withArray :: Storable a => [a] -> (Ptr a -> IO b) -> IO b I think.. withArrayLength :: Storable a => [a] -> (Ptr a -> Int -> IO b) -> IO b would be useful because you often need the length in a foreign function and I guess withArray must pre-calculate the length before allocating storage in any case (or at least must know the length by the time marshalling is finished). It seems a pity to waste time calculating it twice. Actually, looking at the ffi again I see there is something similar for CStrings already, but not for arrays in general. Is this an oversight or a deliberate decision? Regards -- Adrian Hey
On Wednesday 11 Feb 2004 9:55 am, Adrian Hey wrote:
Actually, looking at the ffi again I see there is something similar for CStrings already, but not for arrays in general. Is this an oversight or a deliberate decision?
Oops, well I guess it's needed for CStrings if they're not necessarily the same length as the Haskell list (as seems to be the case). But it would be nice to have it for arbitrary arrays too. Regards -- Adrian Hey
Adrian Hey wrote:
[...] I think..
withArrayLength :: Storable a => [a] -> (Ptr a -> Int -> IO b) -> IO b
would be useful because you often need the length in a foreign function
I would support that, similar situations happened a few times in my OpenGL/GLUT stuff.
and I guess withArray must pre-calculate the length before allocating storage in any case [...]
Yep. Cheers, S.
Once upon a time, I wrote:
Adrian Hey wrote:
[...] I think..
withArrayLength :: Storable a => [a] -> (Ptr a -> Int -> IO b) -> IO b
would be useful because you often need the length in a foreign function
I would support that, similar situations happened a few times in my OpenGL/GLUT stuff.
and I guess withArray must pre-calculate the length before allocating storage in any case [...]
Yep.
There has been no other response yet, so I'd like to raise this issue again. If we decide to add this to the module, it should be documented in the FFI addendum as well, BTW. Any opionions? Cheers, S.
On Tue, 2004-03-23 at 05:55, Sven Panne wrote:
Once upon a time, I wrote:
Adrian Hey wrote:
[...] I think..
withArrayLength :: Storable a => [a] -> (Ptr a -> Int -> IO b) -> IO b
would be useful because you often need the length in a foreign function
I would support that, similar situations happened a few times in my OpenGL/GLUT stuff.
and I guess withArray must pre-calculate the length before allocating storage in any case [...]
Yep.
There has been no other response yet, so I'd like to raise this issue again. If we decide to add this to the module, it should be documented in the FFI addendum as well, BTW. Any opionions?
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? Manuel
Hello, I'd like to second Svens second seconding of my request. In my original post saying that "you often need the length" rather understates the case I think. Occasions where you don't need the length seem to be quite rare (for me at least). Also, this function may enable more space efficient code by implementing some kind of lazy marshalling scheme, whereby the memory allocated to the array was extended as required as list evaluation proceeded. Dunno if that's technically feasible in the rts of various Haskell implementations though. But if it is, it won't save any memory with things as they are because we need to hang on to the entire list in order to calculate it's length :-( Regards -- Adrian Hey On Tuesday 23 Mar 2004 12:51 am, Manuel M T Chakravarty wrote:
On Tue, 2004-03-23 at 05:55, Sven Panne wrote:
Once upon a time, I wrote:
Adrian Hey wrote:
[...] I think..
withArrayLength :: Storable a => [a] -> (Ptr a -> Int -> IO b) -> IO b
would be useful because you often need the length in a foreign function
I would support that, similar situations happened a few times in my OpenGL/GLUT stuff.
and I guess withArray must pre-calculate the length before allocating storage in any case [...]
Yep.
There has been no other response yet, so I'd like to raise this issue again. If we decide to add this to the module, it should be documented in the FFI addendum as well, BTW. Any opionions?
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?
Manuel
_______________________________________________ FFI mailing list FFI@haskell.org http://www.haskell.org/mailman/listinfo/ffi
On Tuesday 23 Mar 2004 12:51 am, Manuel M T Chakravarty wrote:
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?
Oops, I forgot to answer your main question. Yes, that seems to be a reasonable approach to me. I don't think anybody expects the official FFI documentation to updated piecemeal whenever a new function is added. But it would be nice if all FFI implementations agreed (informally) on what extensions they were going to implement. Regards -- Adrian Hey
On Mon, Mar 22, 2004 at 07:55:51PM +0100, Sven Panne wrote:
Once upon a time, I wrote:
Adrian Hey wrote:
[...] I think..
withArrayLength :: Storable a => [a] -> (Ptr a -> Int -> IO b) -> IO b
I support that as I came across C functions that needed an array and it's length rather often.
Axel.
participants (4)
-
Adrian Hey -
Axel Simon -
Manuel M T Chakravarty -
Sven Panne