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: seq as a class method
John Hughes: > Wolfgang Jeltsch: > >it seems that there is not yet a ticket about putting seq into a type class > >(again). And I hope it stays that way. > This sounds like a good idea in principle, but it was a nightmare in > practice. > > First, the implementation details and the difference between _|_ and > const _|_ > make a difference to space behaviour, and one needs a way to control that. > Hiding the differences can make space leaks *impossible* to fix. Along similar lines: I like Haskell being lazy, but it has to make it easier for the programmer to enforce eager evaluation where necessary for good resource utilisation. `seq' already is annoying and inconvenient (as it forces you to re-arrange your code), let's not make it worse. I'd like Haskell' to make it easier to force evaluation, which is why I like the bang pattern proposal. Manuel ___ 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
concurrency
Hello all,
Haskell implementation can have one of 4 levels of concurrency
support:
1) no support at all
2) emulation of concurrency primitives ("blocked" ffi calls, MVar via
IORef and so on)
3) cooperative concurrency
4) preemptive concurrency
imho, it would be great to prohibit 1) and define requirements to the
2)-4) in the standard
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
Re: seq as a class method
it seems that there is not yet a ticket about putting seq into a type class (again). In my opinion, having seq available for every type is a serious flaw. One problem is that the law f = \x -> f x doesn't hold anymore since the equation is false for f = _|_. There was also a discussion on one of the mailing lists some time ago which revealed that the Monad instance for IO doesn't satisfy the monad laws because of the availability of seq for IO, I think. In addition, the automatic definition of seq for every type can make implementation details visible which were thought of as completely hidden. For example, it might make a difference whether one uses data or newtype for a one-alternative-one-field datatype, even if the data constructor is hidden. I therefore propose to declare a class like this: class Seq a where seq :: a -> b -> b Oh please, no. This sounds like a good idea in principle, but it was a nightmare in practice. First, the implementation details and the difference between _|_ and const _|_ make a difference to space behaviour, and one needs a way to control that. Hiding the differences can make space leaks *impossible* to fix. Secondly, the need to insert and remove Seq contexts from type signatures during space debugging is a major overhead. In my practical experience such overheads made some desirable refactorings impossible to carry out in the time available for the project. Thirdly, the laws one loses are "nearly true" anyway, and that's very often enough. See "Fast and loose reasoning is morally correct", POPL 2006. We don't need to give up anything to make reasoning *as though* such laws held sound, in most cases. John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Ticket #15: add a binary IO interface
Hello Bulat, Wednesday, March 22, 2006, 4:38:13 PM, you wrote: BZ> about this - i'm almost sure that current widely used libraries BZ> (NewBinary) is not as good as my own one BZ> (http://freearc.narod.ru/Streams.tar.gz) is not ever used and even BZ> still not documented, so it is not easy to make right choice :) sorry. this can be misunderstood, i want to say that _my_ library is not ever used and its AltBinary part is not documented -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ 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: Re[2]: the MPTC Dilemma (please solve)
Manuel M T Chakravarty writes: > > Another thing, here's an excerpt of the current summary of the MPTC > > dilemma from > > http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki > > > > > > Multi Parameter Type Classes Dilemma ¦ > > > > Options for solving the dilemma ¦ > > 2. Put AssociatedTypes on the fast-track for sainthood > > > > Associated Types ¦ > > > >Cons ¦ > > * Only a prototype implementation so far > > > > This is a *inaccurate* and highly *misleading* summary. > > I didn't write that wiki page plus you are citing individual sentences > out of a larger text. This wasn't meant as a "personal attack". If you (or whoever wrote) feel offended, I'm sorry. Fact is: (risking that I repeat myself here) - When it comes to typing, FDs strictly subsume ATs. (FDs = as defined in the FD-CHR paper) FYI, the next Chameleon release will supports FDs and ATs, ATs are internally represented via FD-CHRs. - All the challenging inference problems encountered for FDs also apply to ATs (see my previous emails) - FD-CHRs describe improvement *and* instance, superclass rules. It's really the subtle interaction between improvement and instances that causes the problem. I also would like to point that none of the FD-CHR results are "recent". The FD-CHR paper was published in ESOP'04, that was two years ago. Since April 2004, there's an extended version available as a TR. Correct, a revised version will somewhen soon appear as a JFP paper. Martin ___ 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
