ANN: H98 FFI Addendum 1.0, Release Candidate 10

[Ross Paterson]

On Sun, Jun 08, 2003 at 10:36:48PM +1000, Manuel M T Chakravarty wrote:
> Done.
> Done.
> Done.

Thanks, that's much safer.  It's just nitpicking now, but:

> > Having washed our hands of unsafePerformIO applied to non-deterministic
> > actions, we no longer need the third paragraph, which (though scary)
> > provides no useful guidance:
> > 
> > - Great care should be exercised in the use of this function.  Not only
> > - because of the danger of introducing side effects, but also because
> > - \code{unsafePerformIO} may compromise typing, for example, when it is used
> > - in conjunction with polymorphic references.
> 
> I don't quite agree with this.  John's IORef example is
> indeed outlawed by the determinism requirement.  However, it
> is possible to construct examples that are deterministic,
> but still dubious from a typing perspective.  Let's assume a
> C routine
> 
>   void *foo();
> 
> that *always returns the same pointer* to a buffer area.  To
> bind this in Haskell as
> 
>   foreign import ccall foo :: Ptr a
> 
> is problematic[1].

I wouldn't consider that an environment-independent value.

> Great care should be exercised in the use of this function.  Not only
> because of the danger of introducing side effects, but also because
> \code{unsafePerformIO} may compromise typing; in particular, the result of
> \code{unsafePerformIO} should always have a monomorphic type.

Unlike the other restrictions, this one could be checked by a compiler,
but perhaps it's too strict.  The problem isn't polymorphism as
such, but polymorphic storage references, and I claim they're either
environment-dependent or ill-typed.  I also suspect there may be some
perfectly reasonable polymorphic examples, though I can't think of a
realistic example offhand.

In any case, it's not accurate to call it a function.

> Moreover, we could use a stable pointer to store a reference
> to an IORef in C land and use this to construct something
> not unlike John's example.  In contrast, to John's example,
> we would always get the same IORef (so the function is
> deterministic), but could still give it the polymorphic type
> that it shouldn't have.

I don't see how this will fly.

Typo: in 6.2 CTypes, the second and third bulleted paras have T for CT.