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. though, it would not surprise me if many did not support "reentrant blockable" as it is a real pain to do properly. or, to put it another way, if they were not separate concepts then cooperative implementations would have no choice but to reject any program using 'safe' since there is a chance they might mean 'reentrant blockable' rather than just reentrant or just blockable. John -- John Meacham - ⑆repetae.net⑆john⑈