Ross Paterson
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