ANN: H98 FFI Addendum 1.0, Release Candidate 10

[Manuel M T Chakravarty]

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

> On Fri, May 23, 2003 at 07:33:05AM +1000, Manuel M T Chakravarty wrote:
> > Dear Haskell Folks,
> > 
> > Release Candidate 10 of the H98 FFI Addendum 1.0 is now
> > available from
> > 
> >   http://www.cse.unsw.edu.au/~chak/haskell/ffi/
> 
> I have an ideological objection.  I think that the inclusion of
> unsafePerformIO in an Addendum sends entirely the wrong signal.  I know
> it's needed for marshalling for otherwise pure functions that pass their
> data through pointers.  Very well, but the inclusion of unsafePerformIO
> allows many more uses.  At a stroke it removes many of the trickiest
> design problems of Haskell, and we can't have that.
> 
> I propose that the Addendum say that it permits unsafePerformIO for that
> purpose only, i.e. the IO calls it contains are restricted to foreign
> calls and functions from Storable and Marshal*, these may only access
> Ptr's inaccessable outside the unsafePerformIO, and no other visible
> side effects are permitted.

Well, the text already says,

\item[unsafePerformIO ::\ IO a -> a] Execute an \code{IO} action in place of a
  pure computations.  For the behaviour to be predictable, the IO computation
  should be free of side effects and independent of its environment.
  
  If the \code{IO} computation wrapped in \code{unsafePerformIO} performs side
  effects, then the relative order in which those side effects take place
  (relative to the main \code{IO} trunk, or other calls to
  \code{unsafePerformIO}) is indeterminate.
  
  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 think, the warning sign is clear.  Especially in the
context of the FFI, anything more is a waste of paper IMHO.
After all, you can import any C function with a pure type,
which also allows you to wreck arbitrary havoc.  We enable
the user to disguise arbitrary machine code as a Haskell
function of essentially arbitrary type.  In comparison,
`unsafePerformIO' seems angelic.

Cheers,
Manuel