FFI, safe vs unsafe

[John Meacham]

On Wed, Mar 29, 2006 at 02:05:35PM +0100, Simon Marlow wrote:
> > 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. 

yeah, but sometimes efficiency hacks become so pronounced they turn into
correctness problems. (tail-call optimization being the canonical
example) 


> 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.

It would be a very odd thing to disallow, seeing as how it would rule
out or at least place fairly large implementation restrictions on
yhc,hugs and jhc and not a single foreign import in the standard
libraries needs to be 'blockable reentrant' as far as I can tell.

though, I do need to look at hugs and yhcs source more carefully to know
whether that is the case for sure. it depends on a lot of implementation
details and how they handle OS-level threads and blockable in general.


> 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 -}

I don't really like the word 'unsafe' because it doesn't really tell you
much about what is actually unsafe. I'd go with the more descriptive:

>   nonreentrant
>   concurrent nonreentrant
>   concurrent          -- the hard one
>   {- nothing -}


where 'nonreentrant' means a proof obligation is on the programmer to
show that routine does not call back into the haskell run-time.  This
feels more future-safe too in case we add another unrelated type of
unsafety in the future.


        John


-- 
John Meacham - ⑆repetae.net⑆john⑈