Ross Paterson wrote:

...

http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrency

Do you envisage Haskell' implementations that do not support concurrency?

This is one of the outstanding questions in the proposal itself. To aid discussion, here is what the proposal says:

* Standardise on Concurrent Haskell without STM. It is our view that even in the presence of STM, MVars offer functionality that is distinct from STM and separately useful, so this leaves room for growth.

* Use the semantics from Extending the Haskell FFI with Concurrency

Questions: * Decide how much pre-emption is acceptable, and figure out how to specify this.

* Should we specify what an implementation that doesn't provide concurrency should do? (e.g. provide an implementation of MVars in terms of IORefs, so that concurrency-safe libraries can be written portably).

* Require bound thread support, or make it optional? (YHC has concurrency with non-blocking foreign calls, but doesn't have bound threads as yet.)

So as I understand it, the idea is basically to record the "state of the art" in current practice as an addendum to the Report - yes? If your implementation claims to do concurrency, then it must do it (at least) in conformance to the semantics of the addendum. If you do not implement concurrency, then obviously it doesn't apply. But Q2 explicitly raises the issue of whether a non-concurrent implementation must still follow a minimum API. That could be a reasonable requirement, if we fleshed out the detail a bit more. The specific suggestion of requiring MVars makes me a tiny bit worried though. After all, MVars capture the idea of synchronisation between threads, and I assume that since a non-concurrent implementation has only one thread, that thread will be trying to MVar-synchronise with something that does not exist, and hence be blocked for ever. I can imagine that there are situations where synchronisation is entirely safe and free of blocking, but how to specify when it would be unsafe? (As an interesting aside, I believe yhc implements IORefs in terms of MVars, rather than the other way round...) Regards, Malcolm

John Goerzen wrote:

On Fri, Mar 24, 2006 at 11:07:53AM +0000, Malcolm Wallace wrote:

...

I assume that since a non-concurrent implementation has only one thread, that thread will be trying to MVar-synchronise with something that does not exist, and hence be blocked for ever.

Not necessarily. An MVar is a useful tool in place of an IORef. It works well when a given hunk of code is used in a threaded program, but it also works well in a non-threaded program. If they are used correctly, there is no problem.

Your final sentence is the one that I want to emphasise. What does it mean to use an MVar "correctly", such that one can avoid blocking in a non-threaded implementation? Regards, Malcolm