RE: important news: refocusing discussion
On 24 March 2006 12:28, Ross Paterson wrote:
On Fri, Mar 24, 2006 at 11:30:57AM -0000, Simon Marlow wrote:
So I believe the issue is mainly one of perspective. Until I wrote this email I hadn't thought of (4) and my preference was for (2), but now I quite like the idea of (4). We would include concurrency in Haskell', but provide a separate addendum that specifies how imlementations that don't provide concurrency should behave. One advantage of (4) over (3) is that we can unambiguously claim that Haskell' has concurrencey.
And we can unambiguously state that there is only one Haskell' implementation (though a second is on the way).
Sure, concurrency is essential to many applications, and should be precisely specified. But it is also irrelevant to a lot of uses of Haskell (except for ensuring that one's libraries are also usable on concurrent implementations, as JohnM said). A specification of the language without concurrency would be at least as valuable (having more implementations). Perspective, as you say -- most people agree we need both -- but I think you're a bit too negative about the smaller variant.
This is just a difference of opinion, and probably won't be easily resolved. It comes down to whether you think Haskell' should be a language that is wide enough to include such applications as a web server, or whether it has to stop short of including concurrency because it's too hard to implement (and it's not always hard - the YHC guys managed it in a matter of days, but I do realise it would be hard in Hugs). I think it would be a mistake to relegate concurrency to an addendum; it is a central feature of the language, and in fact is one area where Haskell (strictly speaking GHC) is really beginning to demonstrate significant advantages over other languages. We should make the most of it. Cheers, Simon
Simon Marlow:
On 24 March 2006 12:28, Ross Paterson wrote:
On Fri, Mar 24, 2006 at 11:30:57AM -0000, Simon Marlow wrote:
So I believe the issue is mainly one of perspective. Until I wrote this email I hadn't thought of (4) and my preference was for (2), but now I quite like the idea of (4). We would include concurrency in Haskell', but provide a separate addendum that specifies how imlementations that don't provide concurrency should behave. One advantage of (4) over (3) is that we can unambiguously claim that Haskell' has concurrencey.
And we can unambiguously state that there is only one Haskell' implementation (though a second is on the way).
Sure, concurrency is essential to many applications, and should be precisely specified. But it is also irrelevant to a lot of uses of Haskell (except for ensuring that one's libraries are also usable on concurrent implementations, as JohnM said). A specification of the language without concurrency would be at least as valuable (having more implementations). Perspective, as you say -- most people agree we need both -- but I think you're a bit too negative about the smaller variant.
This is just a difference of opinion, and probably won't be easily resolved. It comes down to whether you think Haskell' should be a language that is wide enough to include such applications as a web server, or whether it has to stop short of including concurrency because it's too hard to implement (and it's not always hard - the YHC guys managed it in a matter of days, but I do realise it would be hard in Hugs).
I think it would be a mistake to relegate concurrency to an addendum; it is a central feature of the language, and in fact is one area where Haskell (strictly speaking GHC) is really beginning to demonstrate significant advantages over other languages. We should make the most of it.
I 100% agree!! Personally, I think, after the FFI, a good story about concurrency and exceptions is what H98 misses most for applications other than variations on the compiler theme. Manuel
On Fri, Mar 24, 2006 at 02:47:09PM -0000, Simon Marlow wrote:
I think it would be a mistake to relegate concurrency to an addendum; it is a central feature of the language, and in fact is one area where Haskell (strictly speaking GHC) is really beginning to demonstrate significant advantages over other languages. We should make the most of it.
Essential for many applications, certainly, but central? How can you say that?
Hello Ross, Saturday, March 25, 2006, 4:16:01 AM, you wrote:
On Fri, Mar 24, 2006 at 02:47:09PM -0000, Simon Marlow wrote:
I think it would be a mistake to relegate concurrency to an addendum; it is a central feature of the language, and in fact is one area where Haskell (strictly speaking GHC) is really beginning to demonstrate significant advantages over other languages. We should make the most of it.
Essential for many applications, certainly, but central? How can you say that?
it becomes central language feature just because it's much easier to write concurrent programs in Haskell than in other languages and because ghc's implementation of "user-level threads" is blazing fast, outperforming closest competitor in hundreds (!) times in the Language Shootout concurrency testing so, the concurrent programming, may be, the only area at now, where real-world, commercial programmers should prefer Haskell over all other languages. in this light, leaving the concurrency outside of language standard will decrease our chances of pushing the language to the commercial arena and gathering "critical mass" of Haskellers -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Sat, 2006-03-25 at 13:17 +0300, Bulat Ziganshin wrote:
Hello Ross,
Saturday, March 25, 2006, 4:16:01 AM, you wrote:
On Fri, Mar 24, 2006 at 02:47:09PM -0000, Simon Marlow wrote:
I think it would be a mistake to relegate concurrency to an addendum; it is a central feature of the language, and in fact is one area where Haskell (strictly speaking GHC) is really beginning to demonstrate significant advantages over other languages. We should make the most of it.
Essential for many applications, certainly, but central? How can you say that?
it becomes central language feature just because it's much easier to write concurrent programs in Haskell than in other languages and because ghc's implementation of "user-level threads" is blazing fast, outperforming closest competitor in hundreds (!) times in the Language Shootout concurrency testing
I don't think "central to the language" is a particularly helpful concept here. Let's try to frame debates like this in terms of "interests", not "positions". That is, an interest is "we should be able to write thread-safe libraries" and a position is "Haskell' should have concurrency". Once we understand each-others' interests, we can look to find solutions that satisfy a compelling set of interests. I'll try to frame some interests that various folks seem to have expressed, and I admit that I may miss some and be wrong, so please add to or correct the list below (maybe it should go on the wiki): Possible Interests: 1. I can write tools like filesystems, web servers, and GUIs in Haskell' 2. Libraries that I use are thread-safe 3. I can compile my code with any Haskell' compiler 4. Tools such as debuggers and tracers that claim to support Haskell' actually work on my code. 5. That there not be "too many Haskell's" 6. That there be a diversity of Haskell' implementations 7. That concurrency be reasonable to implement for existing compilers/interpreters. 8. That it be reasonable to implement for new compilers/interpreters. 9. Show off how effective Haskell can be in this area (possibly attracting new users). By 5 I mean that it might be nice to have a "core" Haskell and a bunch of addenda. But this could cause no two Haskell' implementations to be the same. (My Haskell' might have concurrency and FFI, but no class system, or something.) The more optional addenda we have, the more we actually fracture the language. We could be in the same situation we're in today. Isaac's Interests * 1-6, 9 Simon's Interests: * He's mentioned 9, I'm sure that there are others. Ross and John Meacham I think have both expressed worry about 7 and 8. I have no idea if it would work, but one solution that Simon didn't mention in his enumeration (below) is that we could find a group of people willing to work hard to implement concurrency in Hugs, for example, under Ross's direction. That might satisfy interest number 7. Please help me to build this understanding of various folks' interests, an solutions to satisfy them. peace, isaac Simon Marlow Wrote:
It boils down to a choice between:
(1) Haskell' does not include concurrency. Concurrent programs are not Haskell'.
(2) Haskell' includes concurrency. Concurrent programs are Haskell', but there are some compilers that do not implement all of Haskell'.
(3) There are two variants of Haskell', Haskell' and Haskell'+Concurrency. Compilers and programs choose which variant of the language they implement/are implemented in.
(4) The same as (3), but the two variants are Haskell' and Haskell'-Concurrency (where -Concurrency is a negative addendum, an addendum that subtracts from the standard).
--
isaac jones
On Sat, Mar 25, 2006 at 05:31:04PM -0800, isaac jones wrote:
I have no idea if it would work, but one solution that Simon didn't mention in his enumeration (below) is that we could find a group of people willing to work hard to implement concurrency in Hugs, for example, under Ross's direction.
I'm no expert on Hugs internals, and certainly not qualified to direct such an effort, but I don't have great hopes for it. Apart from the fact that Hugs is written in a legacy language and uses a quite a bit of global state, it also makes heavy use of the C stack, and any implementation that does that will have trouble, I think. I think it's clear that the proposed concurrency model is feasible for some implementations but not for others. I've been assuming that Haskell' was intended to encompass a wide range of implementations. If that's the case, the key point is that a Haskell' module that does not use concurrency, but is thread-safe, ought to work with non-concurrent implementations too. To make that work, we'd need two interfaces: * one for applications that make use of concurrency. This would be unavailable on some implementations. * one for thread-safe use of state. This would be available on all implementations, and authors not requiring concurrency would be encouraged to use it for maximum portability.
it's too hard to implement (and it's not always hard - the YHC guys managed it in a matter of days
Tom is the one who implemented it in Yhc, and details can be found http://www.haskell.org/haskellwiki/Yhc/RTS/Concurrency but some of the reasons that it was easier than in other compilers are: * We compile to byte code, then execute the bytecode. Because of this, to add support for concurrency only really changes the executer, which is a standalone program. * Bytecode also means we can just schedule each process for n instructions. * Its simulated concurrency, if you have two processors, only one will ever be used. The only exception is FFI, where a number of FFI calls can run in parallel with some Haskell code. This means that no locking is needed on the global heap. If compiling to native code, and aiming for proper concurrency at the operating system level, it would be a lot more work! If you wanted high performance concurrency, like GHC, you would need to do that extra work. Thanks Neil
"Simon Marlow"
I think it would be a mistake to relegate concurrency to an addendum; it is a central feature of the language, and in fact is one area where Haskell (strictly speaking GHC) is really beginning to demonstrate significant advantages over other languages. We should make the most of it.
I agree. Concurrency is needed for finalizers (except those which only call system functions, without mutating other objects). -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
participants (7)
-
Bulat Ziganshin -
isaac jones -
Manuel M T Chakravarty -
Marcin 'Qrczak' Kowalczyk -
Neil Mitchell -
Ross Paterson -
Simon Marlow