Manuel wrote:
[...]
* I want to get v1.0 of the spec fixed. We are really only
in bug fix mode for quite a while and only the finalizer
problems held us back from finishing the spec.
That's OK and I understand your motivation. Let's finish v1.0 first.
* I am sure there are plenty more
Alastair Reid [EMAIL PROTECTED] wrote,
perhaps ForeignPtr should not be an instance of Eq so people can
provide their own?
Note that if we did this, we'd want to consider adding an operation
eqForeignPtr :: FP a - FP a - Bool
FP b-- possible variant
On Mon, Jan 20, 2003 at 11:03:36PM +1100, Manuel M T Chakravarty wrote:
Hence, I propose to leave the definition in the spec as it
was; ie, the equality of ForeignPtrs is defined via the
vanilla pointer that they encapsulate.
However, if you generalize ForeignPtrs (which I hope you will) this
On Fri, Jan 17, 2003 at 10:23:27AM +1100, Manuel M T Chakravarty wrote:
Ross Paterson [EMAIL PROTECTED] wrote,
I'd also like to see the addition of
mallocForeignPtrArray :: Storable a = Int - IO (ForeignPtr a)
to ForeignPtr, to save people from rolling their own. (Maybe the
Sven Panne [EMAIL PROTECTED] writes:
Yet another change request for the FFI libraries: For reasons of
consistency, I propose to introduce an intermediate module
Foreign.Marshal, which re-exports the modules:
Foreign.Marshal.Alloc
Foreign.Marshal.Array
Foreign.Marshal.Error
Manuel wrote:
[...]
* I want to get v1.0 of the spec fixed. We are really only
in bug fix mode for quite a while and only the finalizer
problems held us back from finishing the spec.
That's OK and I understand your motivation. Let's finish v1.0 first.
I agree, but I don't have
Simon Marlow wrote:
[...] So we might well ask what useful new functionality is provided
by a pool-style memory manager.
Well, I guess that about 90% of the hierarchical libraries don't provide
any new functionality, but nevertheless they provide useful
abstractions. The same holds for my
On 20-Jan-2003, Simon Marlow [EMAIL PROTECTED] wrote:
So, assuming the performance is roughly the same (I'm guessing that
using pools may be slightly faster than mallocForeignPtr, but not
significantly)
I am not yet convinced that this is a reasonable assumption if you
are considering a wide