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
Re: concurrency (was Re: important news: refocusing discussion)
On Tue, Mar 28, 2006 at 11:05:03AM +0100, Malcolm Wallace wrote: > 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. it is true if you omit forkIO. as in, any use of MVars that cannot dead-lock and doesn't use forkIO in a concurrent setting, can't deadlock in a non-concurrent one. it is possible to write programs that only won't deadlock in a concurrent setting, but _only_ if you explicitly use forkIO at some point so we still have our static guarentees about deadlocks. > 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. dear golly no. that is part of the point of IORefs, the memory barriers needed by MVars are _extremely_ expensive compared to the simple memory accesess that IORefs should encompass, you don't want to use MVars except when absolutly needed. when using IORefs it is your responsibility to ensure they are used solely from within a single thread, the same way it is your responsibility to not deadlock when using MVars. > * One can write single-threaded code using MVars instead of IORefs, > and it will be safe on a multi-threaded implementation. but much much less efficient on multi-threaded systems if you knew the refs would only be used in a single threaded manner (as is the case for most uses of iorefs) We do need to say something about the distinction between IORefs and MVars in the report, but getting rid of IORefs would be a horrible mistake if we want our concurrent implementations to be fast. if nothing else, we lose the intent of the programmer. I would even go so far as to disallow the IORef protected by MVar usage model just to be future-safe. but that might be too unpopular and STM sort of makes it less important to worry about. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ 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
On 27 March 2006 18:51, Neil Mitchell wrote: > * 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. I don't consider this to be "simulated" concurrency. The fact that you don't get any actual parallelism on a multiprocessor is a performance issue, not a semantic one. In other words, your implementation is fine. Until very recently GHC had the same restriction, incedentally. Cheers, Simon ___ 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
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
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
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
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 Fri, Mar 24, 2006 at 11:07:53AM +, Malcolm Wallace wrote: > 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 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. -- John ___ 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 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
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. ___ 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
Ross Paterson <[EMAIL PROTECTED]> 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 ___ 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
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 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
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=new&status=assigned&status=reopened&group=topic&component=Proposal&order=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
Re: important news: refocusing discussion
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? -- Ashley Yakeley, Seattle WA WWED? http://www.cs.utexas.edu/users/EWD/ ___ 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
