On Fri, Nov 30, 2012 at 5:36 PM, Simon Peyton-Jones <simonpj@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-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of Nate Soares Sent: 27 November 2012 22:44 To: Ben Millwood Cc: haskell-prime@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 <haskell@benmachine.co.uk> wrote:

On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh <igloo@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-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

-- Your ship was destroyed in a monadic eruption.

* Simon Peyton-Jones <simonpj@microsoft.com> [2012-11-30 16:36:01+0000]

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<http://hackage.haskell.org/trac/haskell-prime/wiki/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!

Thanks — I think this is a good analysis of the situation. One thing I'd like to add is that working on the standard not only takes more effort compared to responding on the mailing list, but it also requires a much higher level of competence. Roman