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⑈
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
