On Sat, Dec 1, 2012 at 3:36 AM, Gábor Lehel <illiss...@gmail.com> wrote:
> > But in Haskell right now, for practical purposes, we don't have competing implementations. We have GHC. Isn't "putting pressure on the community" for a new standard a way to, umm, implement wished-for features in GHC economically? ;) -- Kim-Ee On Sat, Dec 1, 2012 at 3:36 AM, Gábor Lehel <illiss...@gmail.com> wrote: > On Fri, Nov 30, 2012 at 5:36 PM, Simon Peyton-Jones > <simo...@microsoft.com> wrote: > > I'd argue that it's not. Haskell hasn't had a release in years, and I > think > > it's time to put a little pressure on the community. > > > > > > > > The question is: who is “the community”? > > > > > > > > It’s fairly clear that the Haskell Prime process itself is languishing. > The > > last message about the development process that I can find is this one > from > > Malcolm Wallace, in January 2011. > > > > > > > > But please don’t blame Malcolm or the committee. Developing new, > > well-specified changes to Haskell will only happen if there is a vigorous > > eco-system of folk who are prepared to devote the love and time to do it. > > There are plenty of people (myself among them) who would be delighted if > > there was a series of well-specified updates to the Haskell standard; > but it > > is harder to assemble a group that is willing to move that process > forward. > > > > > > > > Why not? I don’t think it’s laziness or selfishness; just look at how > > helpful people are on the mailing list. Rather, I am guessing that it’s > a > > subconscious assessment of cost/benefit. The cost is certainly > significant, > > and (unlike a quick email response on Haskell Cafe) takes place over > months. > > > > > > > > The benefit, for an individual, is harder to articulate. GHC defines a > > de-facto standard, simply by existing, and for many practical purposes > that > > is good enough. However, GHC is (quite consciously) exploring stuff that > > may or may not ultimately turn out to be a good idea: it’s a laboratory, > not > > an every-detail-thought-out product. [Though of course we try hard to be > > good enough for production use.] So there is real merit in having a > group, > > not too closely coupled to GHC, that picks off the best ideas and > embodies > > them in a language standard. But if for any one individual, GHC is > “good > > enough”, then the benefits of a language standard may seem distant and > > diffuse. > > > > > > > > I don’t have a solution to this particular conundrum. As many of you > will > > remember, the Haskell Prime process was itself developed in response to a > > sense that making a “big iteration” of the language was so large a task > that > > no one felt able to even begin it. Hence the deliberately more > incremental > > nature of Haskell Prime; but even this lighter-weight process is rather > > stuck. > > > > > > > > I’m sure that any solution will involve (as it did in earlier stages) > > motivated individuals who are willing to take up leadership roles in > > developing Haskell’s language definition. I’m copying this to the main > > Haskell list, in the hope of attracting volunteers! > > > > > > > > Simon > > To take a somewhat contrarian position, but with many of the same points: > > I don't think it's so terrible that the process is languishing. Of > course, a new standard would be nice - so would a pony.* But a > language standard is a solution to a problem that right now, we don't > have. > > The situation when you really want a common standard is when you have > multiple, competing, incompatible implementations. Programs that work > with one implementation don't work with another, and there's no clear > idea of what they "should" do, only what they do. It's really > annoying, and impedes productivity. The solution is to create a > standard that specifies the expected behaviour, and to make all of the > implementations obey it. It's a lot of work, but the payoff is worth > it. If your code works with one implementation, it's likely to work > with another. > > But in Haskell right now, for practical purposes, we don't have > competing implementations. We have GHC. If your code works with GHC, > it's likely to work with GHC. (Heck, the main source of > incompatibilities is /older and newer versions of GHC/.) People get > their work done, their code works, there's no big problem. So while > creating a standard is a lot of work, there's no clear payoff. People > are making the calculation that they have more beneficial uses for > their time than to work on Haskell' - and maybe they're right! > > If someone wants to "put pressure on the community" to work on a new > standard, the thing to do would be to work on another implementation > of Haskell(-with-extensions), and to get it to the point where a > significant chunk of the community has reasons to prefer it over GHC. > Even that feels a bit like putting the cart before the horse, though: > the value would be more in the new, competing implementations and the > different perspectives they afford, than in the new work on Haskell' > that they might inspire. But besides increasing demand for one, I do > think that this would have a positive effect on any hypothetical new > standard and on the process of arriving at it. When making decisions > about the expected behaviour, we would have a rich body of experience > to draw on from the different implementations. Right now, it looks > like "we know what GHC does" and then bikeshedding about "but maybe > another way would be better?", without experience to inform it. > Decisions are harder to make that way, and we can be less certain that > they're right. > > Executive summary: We don't need a new standard right now. If people > don't think it's worth their while to work on it, they're probably > right. New, competing implementations might be valuable. If we have > them, there will be demand for a standard, making decisions about it > will be easier, and it will probably be better. > > That's my two forints. > > - Gábor > > * I don't actually like ponies, but I suppose everyone else does. > > > > > > > > > > From: haskell-prime-boun...@haskell.org > > [mailto:haskell-prime-boun...@haskell.org] On Behalf Of Nate Soares > > Sent: 27 November 2012 22:44 > > To: Ben Millwood > > Cc: haskell-pr...@haskell.org Prime > > Subject: Re: Status of Haskell'? > > > > > > > >> it might be wise to see what GHC decides to do on that front, first, > > > > > > > > I'd argue that it's not. Haskell hasn't had a release in years, and I > think > > it's time to put a little pressure on the community. > > > > > > > > On Tue, Nov 27, 2012 at 2:15 PM, Ben Millwood <hask...@benmachine.co.uk> > > wrote: > > > > On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh <ig...@earth.li> wrote: > >> [...] adding DeriveDataTypeable > >> hopefully wouldn't be too controversial [...] > > > > This is a little tricky since the Data class itself makes (essential, > > I think) use of Rank2Types. Typeable ought to be fine, but it might be > > wise to see what GHC decides to do on that front, first, e.g. whether > > it's going to autoderive all instances or forbid user instances or > > anything else similarly bold. > > > > > > _______________________________________________ > > Haskell-prime mailing list > > haskell-pr...@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-prime > > > > > > > > > > _______________________________________________ > > Haskell-prime mailing list > > haskell-pr...@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-prime > > > > > > -- > Your ship was destroyed in a monadic eruption. > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell >
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
