addForeignPtrFinalizer

[Manuel M T Chakravarty]

Alastair Reid <alastair at reid-consulting-uk.ltd.uk> wrote,

> > I have to say that, given Simon's patch, I am inclined to revert
> > back to the old API for foreign pointers.  
> 
> I don't think such a change should be made unless Malcolm and I are
> able to implement it.  
> 
> I'm not yet convinced that Simon's patch is as easy or correct as it
> seems and will not be until it has been heavily tested and until I
> have a chance to look carefully at the consequences of the change
> elsewhere in the system.  
> 
> Also, Malcolm reported using a similar trick but that he couldn't get
> it to work reliably (i.e., it was ok if the finalizer did nothing but
> call out to C but not otherwise).

I won't change anything until we have finished discussing
the issue, but I got the impression that I probably rushed
the last change.  So, I wouldn't consider the current
definition the default either.

> > The restriction on pure C land finalizers *is* awkward, and as we
> > have already seen implies further changes (ie, adding something like
> > `finalizerFree').
> 
> We missed a small detail in specifying the change and fixed it when we
> went to implement it.  This happens with most design changes and
> doesn't seem like evidence of awkwardness to me.

Fair enough.  However, I still think that the current
definition is awkward.  It is awkward as it goes against the
spirit of the rest of the spec, which strives to accomplish
as much as possible in Haskell, not in C land.  It's awkward
as a user with a fairly big application (namely George) is
inconvenienced by it.  It's awkward because it requires a
subtle side condition on what is a valid finaliser that is
going to trip up users and cause strange errors.

This awkwardness is tolerable if it simplifies the
implementation a lot (as in avoids having to implement
pre-emptive concurrency).  It is not tolerable if it is just
a matter of verifying that an existing implementation
proposal does indeed work (or even if it requires tweaking
that proposal).

At least, this is my understanding of good language design.

Cheers,
Manuel