ANN: H98 FFI Addendum 1.0, Release Candidate 7

[Manuel M T Chakravarty]

Ross Paterson <ross@soi.city.ac.uk> wrote,

> On Thu, Sep 19, 2002 at 10:28:36PM +1000, Manuel M T Chakravarty wrote:
> > Ross Paterson <ross@soi.city.ac.uk> wrote,
> > 
> > > On Thu, Sep 19, 2002 at 12:03:34AM +1000, Manuel M T Chakravarty wrote:
> > > > RC 7 of the FFI Addendum is now available from
> > > > 
> > > >   http://www.cse.unsw.edu.au/~chak/haskell/ffi/
> > > 
> > > Must it include unsafePerformIO?
> > 
> > Sometimes you have a C function that is pure (and hence, you
> > want to give it a pure type), but as C cannot return complex
> > structures as a function result, you need to allocate a
> > piece of memory, pass a pointer to the C function, and read
> > the result out of that memory area on return of the C
> > function.  All this marshaling business requires IO actions;
> > however, it doesn't change the pureness of the overall
> > function.  So, you typically want to unsafePerformIO the
> > marshaling business.
> 
> If the FFI stuff were available with ST variants, and foreign functions of
> this sort could be declared with ST return types, would it be possible to
> replace unsafePerformIO in such cases with runST?  I'm not suggesting that
> the FFI spec should do this now, but if there's a clean alternative on
> the horizon perhaps it would be premature to surrender to unsafePerformIO.

One problem of using ST is that ST is not H98, but the FFI
spec is meant to rely on nothing but H98.

Another problem is that I don't think you would really gain
anything.  runST is safe as given the available ST functions
and the type constraints on runST guarantee that everything
is fine.  Now with an imported C function you will never
have any static guarantee beyond your believe of what the C
routine does.  In particular, you would even break the
safety guarantees that currently exist for the ST monad, as
you could no implement "bad" ST functions.  (A similar
argument can be even made for the marshalling support
functions, as it is impossible to make static guarantees
about the safeness of the peek and poke functions.)

> It also bothers me that though the spec says that the argument to
> unsafePerformIO must be free of side-effects and independent of the
> environment, there's no definition of which combinations of the other
> functions satisfy this requirement.  (ST-based types would do this,
> though.)

I don't really understand your point here.  As soon as you
import C functions, you can't do anything besides handwaving
wrt to the safety of the involved code.  (Well, you could
try to run the C code through a verifier.)

Cheers,
Manuel