Re: important news: refocusing discussion
Simon Marlow [EMAIL PROTECTED] writes: 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 \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: concurrency (was Re: important news: refocusing discussion)
On Tue, Mar 28, 2006 at 10:49:36AM +0100, Malcolm Wallace wrote: Tomasz Zielonka [EMAIL PROTECTED] wrote: http://www.uncurry.com/repos/FakeSTM/ Perhaps it could serve as a drop-in replacement for STM in haskell compilers which don't implement STM directly. Nice idea. But your code already uses a whole heap of Haskell extensions which may or may not make it into Haskell'. monad transformer lib (requires MPTC) exceptions dynamically extensible exceptions deriving non-standard classes extended newtype deriving pattern guards You read the whole code? Wow! I myself would have trouble understanding how it does what it does now ;-) I could easily get rid of: deriving non-standard classes extended newtype deriving pattern guards I used GHC's exceptions, because I wanted my STM to handle them correctly, as in the STM paper. In a implementation without exceptions, I could probably get away with hand made exception handling. The rest would be a bit more difficult to remove, but I think it could be possible more or less elegantly. Best regards Tomasz ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
concurrency (was Re: important news: refocusing discussion)
Tomasz Zielonka [EMAIL PROTECTED] wrote: It may be relevant for this discussion: I believe I reimplemented STM, including retry and orElse, on top of old GHC's concurrency primitives. http://www.uncurry.com/repos/FakeSTM/ Perhaps it could serve as a drop-in replacement for STM in haskell compilers which don't implement STM directly. Nice idea. But your code already uses a whole heap of Haskell extensions which may or may not make it into Haskell'. monad transformer lib (requires MPTC) exceptions dynamically extensible exceptions deriving non-standard classes extended newtype deriving pattern guards Certainly, no compiler other than GHC currently implements all of these extensions. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
concurrency (was Re: important news: refocusing discussion)
Simon Marlow [EMAIL PROTECTED] wrote: The portable interface could be Control.Concurrent.MVar, perhaps. I don't really understand the problem, maybe I'm missing something. I thought the idea would be that a thread-safe library would simply use MVar instead of IORef. I was misled by several people's hand-waving assertion that, provided you used MVars correctly, there would be no synchronisation problems. But no-one had yet defined what correct meant. I kind of assumed they meant you could write concurrent threaded code (with only some minor restrictions) and have it work in a single-threaded implementation without change. This seemed like a pretty strong (and dubious) claim to me. But now I see you are actually saying something quite different. (And I recall some discussion on these points from a few months ago.) * IORef is inherently thread-unsafe, and so we should eliminate IORefs from the language. * One can write single-threaded code using MVars instead of IORefs, and it will be safe on a multi-threaded implementation. The latter point is quite the opposite of what I thought was being proposed. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: concurrency (was Re: important news: refocusing discussion)
On Tue, 2006-03-28 at 11:05 +0100, Malcolm Wallace wrote: (snip) * IORef is inherently thread-unsafe, and so we should eliminate IORefs from the language. That's not quite true, as you can have an IORef guarded by an MVar. Why would you want such a thing? For instance, you might write a library with two IORefs and one MVar instead of two MVars in order to reduce the possibility of deadlock. Is it the case that a library is thread-safe as long as it doesn't use IORefs, though? I trolled around base looking for libraries that might not be thread-safe and found only that HashTable uses an IORef, and indeed there's a FIXME that says it should use an MVar. I didn't look very hard, though. peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: important news: refocusing discussion
John Goerzen [EMAIL PROTECTED] wrote: On Fri, Mar 24, 2006 at 11:07:53AM +, 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: important news: refocusing discussion
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: important news: refocusing discussion
On Wed, Mar 22, 2006 at 10:54:57AM -, Simon Marlow wrote: On 21 March 2006 23:51, isaac jones wrote: Concurrency is summarized here: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrency I have updated the concurrency page with a skeleton proposal. Do you envisage Haskell' implementations that do not support concurrency? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: important news: refocusing discussion
On 24 March 2006 09:55, Ross Paterson wrote: Do you envisage Haskell' implementations that do not support concurrency? Clearly there will be some, the question is what status do they have. 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). I suspect that almost everyone agrees that (1) is not an option. In practical terms, there isn't much to choose between the others: from a programmer's point of view, if they want to use concurrency they still have to choose an implementation that supports it. 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. This also lets us accommodate John Meacham's earlier point, that it should be possible to write concurrency-safe libraries in a portable way, and that means providing parts of Control.Concurrent even in the absence of concurrency. For example, MVars would be provided with an implementation in terms of IORefs. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: important news: refocusing discussion
On 24 March 2006 12:28, Ross Paterson wrote: On Fri, Mar 24, 2006 at 11:30:57AM -, 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: important news: refocusing discussion
Simon Marlow: On 24 March 2006 12:28, Ross Paterson wrote: On Fri, Mar 24, 2006 at 11:30:57AM -, 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: important news: refocusing discussion
On Fri, Mar 24, 2006 at 02:47:09PM -, 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? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: important news: refocusing discussion
On 21 March 2006 23:51, isaac jones wrote: Concurrency is summarized here: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrenc y I have updated the concurrency page with a skeleton proposal. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: important news: refocusing discussion
Simon Marlow: On 21 March 2006 23:51, isaac jones wrote: Concurrency is summarized here: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrenc y I have updated the concurrency page with a skeleton proposal. Yes, good plan. Manuel ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: important news: refocusing discussion
On 3/21/06, isaac jones [EMAIL PROTECTED] wrote: I'd like to ask folks to please bring currently open threads to a close and to document the consensus in tickets. Anyone can edit tickets, so please don't be shy. Claus, can you document some of your FD work in the FunctionalDependencies ticket? I think that the new confluence results lends a lot towards the adoption of FDs in Haskell'. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: important news: refocusing discussion
On Tue, 2006-03-21 at 15:27 -0800, Ashley Yakeley wrote: isaac jones wrote: The topics that John and I feel are critical, and rather unsolved, are: * The class system (MPTC Dilemma, etc) * Concurrency * (One more, perhaps standard libraries) Could you summarise the current state of these? AFAIK, the class system is summarized on this page: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/MultiParamTypeClassesDilemma Although there are some proposals here that are not really covered by that topic, they should probably be considered together: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/query?status=newstatus=assignedstatus=reopenedgroup=topiccomponent=Proposalorder=priority Concurrency is summarized here: http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrency and libraries have not really been discussed much at all. peace, isaac -- isaac jones [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
