FFI, safe vs unsafe

[John Meacham]

On Thu, Mar 30, 2006 at 09:39:44PM +0100, 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?

I think dangerous is a misleading term here. you are already using the
FFI, all bets are off. and it is not really dangerous to accidentally
hold up your VM when you didn't expect, it is more just a simple bug.

Unsafe or dangerous means potentially leading to undefined behavior, not
just incorrect behavior or we'd have to label 2 as unsafe becaues you
might have meant to write 3. :)

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

I think the worse problem will be all the libraries that are only tested
on ghc that suddenly get very poor performance or don't compile at all
when attempted elsewhere.

However, the 'nonreentrant' case actually is dangerous in that it could
lead to undefined behavior which is why that one was not on by default.

        John

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