On Fri, Mar 31, 2006 at 10:21:16AM -0600, John Goerzen wrote:
On Fri, Mar 31, 2006 at 04:41:06AM -0800, John Meacham wrote:
optional preemption - ability to preempt pure code, fairness guarentees, interleaved evaluation operators (merge, nmerge)
Under the "what is provided" section, did you intend that to apply to all compilers, even ones that don't implement threading?
the point is that all compilers will implement threading now and provide everything in that section. rather than having all of concurrency being an option, we have found a way to get a good portion of concurrency guarenteed to be supportable on all systems without any compromises in run-time for the non-concurrent case or restricting the range of future implementation techniques.
If so, we should specify what exception is raised if, say, forkIO is called on such a system. We should also make it clear that single-threaded implementations are required of things such as MVars. Finally, we should add a function that indicates the level of threading support on the running system.
routines that are guarenteed to fail becaues they arn't supported should not exist, haskell tries hard to catch so many errors at compile time, it would seem odd to delegate the error of missing a whole subsystem to run-time :) John -- John Meacham - ⑆repetae.net⑆john⑈
On Fri, Mar 31, 2006 at 01:51:14PM -0800, John Meacham wrote:
If so, we should specify what exception is raised if, say, forkIO is called on such a system. We should also make it clear that single-threaded implementations are required of things such as MVars. Finally, we should add a function that indicates the level of threading support on the running system.
routines that are guarenteed to fail becaues they arn't supported should not exist, haskell tries hard to catch so many errors at compile time, it would seem odd to delegate the error of missing a whole subsystem to run-time :)
Not really. What if I'm writing a program that can take advantage of threading if it's available, but can degrade gracefully if not? Should I be forced to use something like cpphs to detect the presence of threading in advance? It would be better to detect this at runtime than fail to compile at all on a system that doesn't support threading, IMHO. -- John
On Fri, Mar 31, 2006 at 03:59:41PM -0600, John Goerzen wrote:
On Fri, Mar 31, 2006 at 01:51:14PM -0800, John Meacham wrote:
If so, we should specify what exception is raised if, say, forkIO is called on such a system. We should also make it clear that single-threaded implementations are required of things such as MVars. Finally, we should add a function that indicates the level of threading support on the running system.
routines that are guarenteed to fail becaues they arn't supported should not exist, haskell tries hard to catch so many errors at compile time, it would seem odd to delegate the error of missing a whole subsystem to run-time :)
Not really. What if I'm writing a program that can take advantage of threading if it's available, but can degrade gracefully if not? Should I be forced to use something like cpphs to detect the presence of threading in advance? It would be better to detect this at runtime than fail to compile at all on a system that doesn't support threading, IMHO.
Yeah, actually. cpphs (or something in cabal) seems like just the right way to go. because it is set at compile time. you don't make run-time decisions as to whether to use unboxed arrays, control.arrow or any other library. it would seem very odd to do so for concurrency. Concurrency might be hidden deep in a library, you don't want to suddenly get an unexpected "concurrency not supported" error because you happened to use a library you didn't write in a new way. better to be safe and catch those known errors at compile-time. John -- John Meacham - ⑆repetae.net⑆john⑈
On Fri, Mar 31, 2006 at 02:49:53PM -0800, John Meacham wrote:
threading if it's available, but can degrade gracefully if not? Should I be forced to use something like cpphs to detect the presence of threading in advance? It would be better to detect this at runtime than fail to compile at all on a system that doesn't support threading, IMHO.
Yeah, actually. cpphs (or something in cabal) seems like just the right way to go. because it is set at compile time. you don't make run-time decisions as to whether to use unboxed arrays, control.arrow or any other library. it would seem very odd to do so for concurrency.
Well then, this mechanism ought also to be standardized by Haskell'. To support concurrency (or not) but to not provide an automated way of graceful degradation is not, to me, a good solution.
Concurrency might be hidden deep in a library, you don't want to suddenly get an unexpected "concurrency not supported" error because you happened to use a library you didn't write in a new way. better to be safe and catch those known errors at compile-time.
That does make sense. I am concerned about the mechanism. AFAIK, Haskell98 didn't mandate cpphs or any tool like it. Will Haskell'? If not, then we are back to the original problem. -- John
participants (2)
-
John Goerzen -
John Meacham