new ForeignPtr without finalizers

[Alastair Reid]

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
> `newForeignPtr' as to whether there should be a finalizer
> attached.
>
> I guess, the FP-ish solution is to pass an argument of type
> `Ptr a -> IO (ForeignPtr a)' which is `newForeignPtr_' if no
> finalizers should be attached and is `newForeignPtr' already
> applied to a finalizer if a particular finalizers is to be
> attached.  However, then, it would be more convenient to
> change the order of the two arguments to `newForeignPtr'.

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)

Adopting the C idiom seems inappropriate (should use a Haskell idiom for 
Haskell code) and sets a bad example.

Using higher order functions has the problem that the type becomes so general 
that you don't know what you're meant to pass in and certainly can't guess 
that there are only two choices and, despite the hype, function arguments are 
2nd class citizens in Haskell (since you can't print them, compare them, 
etc.)

> 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 report would define 
newForeignPtr in terms of newForeignPtr_ and addForeignPtrFinalizer.)

I'd prefer to avoid swapping the argument order because of code breakage.

--
Alastair Reid