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⑈