OK, I just upgraded to GHC 6.0. How do I create a new ForeignPtr that
doesn't have any finalizers?
newSimpleForeignPtr :: Ptr a -> IO (ForeignPtr a)
newSimpleForeignPtr ptr = ??
--
Ashley Yakeley, Seattle WA
___
FFI mailing list
[EMAIL PROTECTED]
Ashley Yakeley <[EMAIL PROTECTED]> writes:
> OK, I just upgraded to GHC 6.0. How do I create a new ForeignPtr that
> doesn't have any finalizers?
>
> newSimpleForeignPtr :: Ptr a -> IO (ForeignPtr a)
> newSimpleForeignPtr ptr = ??
Why would you want to?
A ForeignPtr without any finalizers
On Monday 09 June 2003 4:59 am, Ashley Yakeley wrote:
> OK, I just upgraded to GHC 6.0. How do I create a new ForeignPtr that
> doesn't have any finalizers?
>
> newSimpleForeignPtr :: Ptr a -> IO (ForeignPtr a)
> newSimpleForeignPtr ptr = ??
There is no direct way in the ffi. You could define
Ashley:
> How do I create a new ForeignPtr that doesn't have any finalizers?
Malcolm:
> Why would you want to?
addForeignPtrFinalizer lets you add them later.
I'm guessing that Ashley is making heavy use of this ability.
[What we have at the moment is the ability to attach a non-empty list of
f
In article <[EMAIL PROTECTED]>,
Alastair Reid <[EMAIL PROTECTED]> wrote:
> It looks like you're using an idiom we didn't think of when designing the
> library. Can you explain what you're trying to do and whether you think we
> shoud provide direct support for newSimpleForeignPtr (which I'd be
In article <[EMAIL PROTECTED]>,
Malcolm Wallace <[EMAIL PROTECTED]> wrote:
> Why would you want to?
>
> A ForeignPtr without any finalizers is semantically just a Ptr,
> plain and simple.
I need a pointer type for which some values have finalizers, and some
don't.
--
Ashley Yakeley, Seattle
Ashley Yakeley <[EMAIL PROTECTED]> writes:
> Specifically I want a ForeignPtr of a null Ptr that has no finalizers.
Ah, this makes sense.
I wonder if we should add the following to the FFI spec module ForeignPtr?
nullForeignPtr :: ForeignPtr a -- a null pointer with null finalizer
Rega
On Mon, Jun 09, 2003 at 01:21:38PM +0100, Malcolm Wallace wrote:
> Ashley Yakeley <[EMAIL PROTECTED]> writes:
>
> > Specifically I want a ForeignPtr of a null Ptr that has no finalizers.
>
> Ah, this makes sense.
> I wonder if we should add the following to the FFI spec module ForeignPtr?
>
>
Alastair Reid <[EMAIL PROTECTED]> wrote,
> Ashley:
> > How do I create a new ForeignPtr that doesn't have any finalizers?
>
> Malcolm:
> > Why would you want to?
>
> addForeignPtrFinalizer lets you add them later.
> I'm guessing that Ashley is making heavy use of this ability.
>
> [What we have
On Monday 09 June 2003 3:48 pm, Manuel M T Chakravarty wrote:
> Andre proposed to allow `nullFunPtr' as a finalizer argument
> to `newForeignPtr' to indicate the lack of a finalizer.
> This seems quite C-ish, but has the advantage that it is
> easy to parametrise functions that internally use
> `ne
Alastair Reid wrote:
> I'm not convinced that merging them into a single function is desirable, but,
> if we wanted to, I think a better FPish solution is to use
>
> Maybe (FinalizerPtr a)
As multiple finalizers are allowed, perhaps we should consider:
newForeignPtr :: [FinalizerPtr a] -> Ptr
In article <[EMAIL PROTECTED]>,
Alastair Reid <[EMAIL PROTECTED]> wrote:
> I'm not convinced that merging them into a single function is desirable, but,
> if we wanted to, I think a better FPish solution is to use
>
> Maybe (FinalizerPtr a)
I think the most FPish solution would be this:
Dean Herington <[EMAIL PROTECTED]> wrote,
> Alastair Reid wrote:
>
> > I'm not convinced that merging them into a single function is desirable, but,
> > if we wanted to, I think a better FPish solution is to use
> >
> > Maybe (FinalizerPtr a)
>
> As multiple finalizers are allowed, perhaps we
Alastair Reid <[EMAIL PROTECTED]> wrote,
> > I'd propose to
> >
> > * add `newForeignPtr_',
> > * reverse the argument order to `newForeignPtr', and
> > * reverse the argument order to `addForeignPointerFinalizer'
> > (for consistency).
>
> I agree with adding newForeignPtr_. (Presumably the r
Manuel:
> In other words, it seem much more likely that one would
> partially apply `newForeignPtr' to a finaliser than to a
> pointer that is to be finalised. But this is a minor point.
Having written some more ffi code over the last couple of days, I agree that
this is much more natural so, ev
On Thu, 12 Jun 2003, Alastair Reid wrote:
> Manuel:
> > In other words, it seem much more likely that one would
> > partially apply `newForeignPtr' to a finaliser than to a
> > pointer that is to be finalised. But this is a minor point.
>
> Having written some more ffi code over the last couple
> Actually, I think I prefer Ashley's idea of separating the creation of a
> ForeignPtr from the addition of a FinalizerPtr. So how about:
>
> newForeignPtr :: Ptr a -> IO (ForeignPtr a)
> addForeignPtrFinalizer :: FinalizerPtr a -> ForeignPtr a -> IO ()
You're proposing a diffe
Dean Herington <[EMAIL PROTECTED]> wrote,
> On Thu, 12 Jun 2003, Alastair Reid wrote:
>
> > Manuel:
> > > In other words, it seem much more likely that one would
> > > partially apply `newForeignPtr' to a finaliser than to a
> > > pointer that is to be finalised. But this is a minor point.
> >
Alastair Reid <[EMAIL PROTECTED]> wrote,
> Manuel:
> > In other words, it seem much more likely that one would
> > partially apply `newForeignPtr' to a finaliser than to a
> > pointer that is to be finalised. But this is a minor point.
>
> Having written some more ffi code over the last couple o
Manuel M T Chakravarty wrote:
> [ newForeignPtr / addForeignPtrFinalizer argument order ]
> This is the last outstanding issue. Shall we swap? I am torn. The
> swapped argument order seems more appropriate, but it will break
> code. Shall we have one more breakage before it's all frozen?
I think th
20 matches
Mail list logo
