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,
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.
That would amount to saying that 'Foreign' isn't a hierarchical library
any more, and anyone
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
On Tue, Mar 23, 2004 at 09:04:35AM -, 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
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?
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 ::
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)
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
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.]
Not wanting
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
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
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
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
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
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
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
16 matches
Mail list logo
