FFI, safe vs unsafe

[Simon Marlow]

On 29 March 2006 13:17, John Meacham wrote:

> On Wed, Mar 29, 2006 at 12:48:54PM +0100, Simon Marlow wrote:
>> I agree with what you say, but let me summarise it if I may, because
>> there's an assumption in what you're saying that's easy to miss.
>> 
>>   IF
>>      the combination of 'blockable' and 'reentrant' is not
>>      required by the standard,
>>   THEN
>>      we should allow foreign calls to be annotated with
>>      one or the other, rather than requiring both.
>> 
>> I agree with this statement, but I don't necessarily agree that the
>> predicate should be true.  Indeed, given that it requires us to
>> complicate the language and puts a greater burden on FFI library
>> writers, there's a good argument not to.
> 
> it is just an implementation fact.
> 
> In jhc (and likely yhc and hugs may find themselves in the same boat)
> 
> unsafe
> blockable
> reentrant
> reentrant blockable
> 
> will all have different concrete implementations and generate
> different code. for correctness reasons, not efficiency ones.

Well, for correctness all you need is reentrant/blockable.  If you have
that, all the others are efficiency hacks.

What you are suggesting is that there may be implementations that do not
support reentrant/blockable, but do support the others.  And in that
case, of course you really need to know the difference between blockable
and reentrant.  I'm just not sure the standard should allow such
implementations.

If we were to go down this route, we have to make reentrant the default:
'unsafe' is so-called for a good reason, you should be required to write
'unsafe' if you're doing something unsafe.  So I'd suggest

  unsafe
  concurrent unsafe
  concurrent          -- the hard one
  {- nothing -}

Cheers,
	Simon