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