> 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 anyo
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 librar
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?
T
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) Ad
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, sw
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) Add
> 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
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 ov
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
leng
> 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 accum
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
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 c
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
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
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-c
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 t
17 matches
Mail list logo