freeHaskellFunctionPtr

[Alastair Reid]

> > I would let freeHaskellFunPtr accept and ignore nullFunPtr, since I
> > once had to write
> >     when (ptr /= nullFunPtr) $ freeHaskellFunPtr ptr
> > and it can be seen as consistent with free.

This sort of behaviour is comon in C but I think this is mostly because C has
such a weak type system.

In the Win32 library, we took some care to distinguish between values which
couldn't possibly be null (whether null pointers, null window handles, null
font handles or whatever) using definitions like this

  newtype Window = Window Addr
  newtype Font   = Font Int32

and values which could possibly be null:

  type MbWindow = Maybe Window
  type MbFont   = Maybe Font

This additional information made it easier to understand function types
(because a bit more of the C documentation had migrated into the Haskell type),
caught programming errors early, etc.

This approach wouldn't be feasible in C because C's type system isn't
expressive enough to express (and check!) these types.  (Well, maybe you could
use unions but it would be so clumsy as to be unusable.)

Which is all just my long-winded way of saying I agree with Simon that we
should not do this.  Even if f.e.d. could return nullFunPtr, we should not do
this because we can express it better using a Maybe.

Alastair