FFI, safe vs unsafe

[Simon Marlow]

On 30 March 2006 21:40, Claus Reinke wrote:

>> I updated the ForeignBlocking wiki page with what I believe is the
>> current state of this proposal; see
> 
> didn't I mention that "concurrent" may be inappropriate and
> misleading, and that I think it is bad practice to rely on the
> programmer annotating the dangerous cases, instead of the safe cases?
> 
> wouldn't the safe approach be to assume that the foreign call may do
> anything, unless the programmer explicitly tells you about what things
> it won't do (thus taking responsibility).

This is the way it is right now in GHC: the default is "safe", and safe
means both reentrant and concurrent.  This is for the reason you give:
the default should be the safest, in some sense.

However, John has argued, and I agree, that requiring the combination of
concurrent and reentrant to be supported is too much, and furthermore is
often unnecessary.

So we can't have the default (unanotated) foreign call be something that
isn't required by the standard.  Hence, the proposal states that
concurrent foreign calls have to be annotated as such, and it is the
specific case of 'concurrent' alone, as opposed to 'concurrent
nonreentrant' that is an extension.

http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/ForeignBlo
cking

Cheers,
	Simon