* Brandon Allbery [2012-11-27 11:44:51-0500]

On Tue, Nov 27, 2012 at 10:50 AM, Nate Soares wrote:

...

I second this question. At what point do we cut Haskell' with what we have, release it, and push the big undecideds back to Haskell"?

Maybe the question is whether we have anything. We already skipped 2011 because there wasn't anything worth the effort of a new standard.

How about MultiParamTypeClasses, RankNTypes, ExistentialQuantification, GADTs? They've been around for quite some time and turned out very useful in practice. Roman

I think it has proven out pretty well in practice that probably want both in the surface language. I know minimalists on the TF side of the debate have tried to make the case that you don't even need FDs in the surface syntax, but there are lots of places where it having a class with multiple directional constraints makes the code much, much more sane. I would be loathe to sacrifice either of them. -Edward On Tue, Nov 27, 2012 at 12:11 PM, Brandon Allbery wrote:

uestion yet? I thought MPTC was not considered usable without one of those, and neither is yet considered standard (with some good reason in the case of FDs).

On Tue, Nov 27, 2012 at 11:44:51AM -0500, Brandon Allbery wrote:

On Tue, Nov 27, 2012 at 10:50 AM, Nate Soares wrote:

...

I second this question. At what point do we cut Haskell' with what we have, release it, and push the big undecideds back to Haskell"?

Maybe the question is whether we have anything. We already skipped 2011 because there wasn't anything worth the effort of a new standard.

FWIW, I stopped working on writing things up as proposals after (TTBOMK) http://www.haskell.org/pipermail/haskell-prime/2011-February/003362.html didn't happen. The big things (GADTs, FD vs AT, etc) are probably still some way off, but there are plenty of incremental changes that we could make now to improve the language. For example, adding negative literals should be simple and would be nice to have, and adding DeriveDataTypeable hopefully wouldn't be too controversial and would help us reach a point where people don't feel the need to use CPP and/or hand-write instances. Thanks Ian

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 wrote:

On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh 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

On Fri, Nov 30, 2012 at 5:36 PM, Simon Peyton-Jones 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 wrote:

On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh 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.

This standardization process amounts to "endorsement of existing features" which seems like not a bad process at all. It makes the standard descriptive rather than predictive.

+1. I agree generally with Gabor's points -- GHC is in the drivers seat. But at some point we should take a look at all the things GHC has made that did pay off and that are good and make them official. I'd very much like to see that endorsement happen soon, even if it's not aggressive.

2012/11/30 Gábor Lehel :

Well, I'm not so sure it's a great idea to just bake "what GHC does at this moment" (for any particular extension) into the standard without really thinking about it. Even then, you have to figure out, in great detail, what GHC does, and write it all down! That's not negligible effort, either. And the alternative is to also publicly discuss and hash all of it out down to the little tiny gritty stuff. But wanting to write a new standard (big effort!) just to get rid of some pragmas and make people feel better (small payoff!) feels like a mismatch to me.

It is a large payoff, considering the thousands and thousands of people that it creates a small payoff for: people writing Haskell, people learning Haskell, people teaching Haskell. A standard is a lot of effort for a handful of people. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B

This is a significant problem for even some of the more ubiquitous extensions. For instance, there are multiple compilers that implement RankNTypes, but I would not be surprised at all if programs using that extension were not portable across implementations (they're not really even portable across GHC versions). The problem is that RankNTypes is not just about the fact that you are allowed to use such types; every compiler must decide on an inference algorithm that incorporates such types while defaulting to Hindley-Milner. But, there are several such algorithms, and they have different trade offs as far as where annotations must be placed, or even whether certain conceivably well-typed terms are type checkable (for instance, GHC used to do some level of impredicative instantiation; forall a. a -> a could be instantiated to (forall a. a) -> (forall a. a); but this no longer works). So, even if we have ubiquitous agreement on the fact that RankNTypes are useful, and implementable, we don't have ubiquitous agreement on the algorithms for implementing them, and which set of trade offs to make. But any standard would have to nail all that down, or else programs won't be portable. And this is not the only extension for which this kind of thing is an issue. -- Dan On Sun, Dec 2, 2012 at 6:42 AM, Ross Paterson wrote:

On Fri, Nov 30, 2012 at 11:05:41PM +0000, Gábor Lehel wrote:

...

Well, I'm not so sure it's a great idea to just bake "what GHC does at this moment" (for any particular extension) into the standard without really thinking about it. Even then, you have to figure out, in great detail, what GHC does, and write it all down! That's not negligible effort, either.

And that is the core of the problem. The standard isn't just a list of approved features. It needs to describe them in such detail that a programmer can tell, from the Report alone, whether a particular program is legal, and if so what it's supposed to do. We don't have that level of description for these extensions, and creating it will be a lot of hard work.

Relying on "what GHC does at the moment" has obvious risks for programmers, it also puts an unfair responsibility on GHC itself. How can they improve a feature if it's current implementation is the "standard"?

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

As far as I know, MPTCs alone do not have this issue. But functional dependencies do, as there are at least two ways they can behave. One is the way they traditionally behave in GHC, and another is the way they would behave if they were sugar for type families. I can't think of anything about MPTCs alone that would be a problem, though. On Sun, Dec 2, 2012 at 2:56 PM, Gábor Lehel wrote:

On Sun, Dec 2, 2012 at 7:06 PM, Dan Doel wrote:

...

This is a significant problem for even some of the more ubiquitous extensions. For instance, there are multiple compilers that implement RankNTypes, but I would not be surprised at all if programs using that extension were not portable across implementations (they're not really even portable across GHC versions).

The problem is that RankNTypes is not just about the fact that you are allowed to use such types; every compiler must decide on an inference algorithm that incorporates such types while defaulting to Hindley-Milner. But, there are several such algorithms, and they have different trade offs as far as where annotations must be placed, or even whether certain conceivably well-typed terms are type checkable (for instance, GHC used to do some level of impredicative instantiation; forall a. a -> a could be instantiated to (forall a. a) -> (forall a. a); but this no longer works).

So, even if we have ubiquitous agreement on the fact that RankNTypes are useful, and implementable, we don't have ubiquitous agreement on the algorithms for implementing them, and which set of trade offs to make. But any standard would have to nail all that down, or else programs won't be portable.

And this is not the only extension for which this kind of thing is an issue.

Out of curiosity, to what degree does MultiParamTypeClasses have this issue? It seems to me like one of the few extensions which is straightforward, widely implemented, uncontroversial, and very useful. For some reason it's been held up by the FDs vs TFs debate, but I don't see why it has to be. Vanilla MPTCs on the one hand, and MPTCs together with either FDs or TFs on the other hand, serve different use cases. If you want a plain type-level relation on types, you use MPTCs. If you want some types to be determined by others, then you use either FDs or TFs. If we standardize support for the former, that's useful, even if we continue to procrastinate on the FDs vs TFs question. So if the idea is to do yearly incremental updates to the standard, MPTCs looks like the biggest low-hanging fruit to me. (Assuming they aren't similarly problematic as RankNTypes.)

-- Your ship was destroyed in a monadic eruption.

On Fri, Nov 30, 2012 at 1:42 PM, Jason Dusek wrote:

It would be nice for there to be a new standard so that many features in GHC -- such as overloaded strings, rank n types, MPTCs, &c. -- were enabled by default without any pragmas.

I think this is one of these nice gains for day-to-day Haskell programming. Less typing and fewer things to explain to beginners ("You see, this might seem like an experimental feature I'm asking you to use, but it really isn't.") -- Johan

Simon wrote:

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!

I, for one, would love to help out! Cheers, Stefan

Stefan, John, Ramana all say: | I, for one, would love to help out! Great stuff. I think the first thing to do is to talk to the 2011 Haskell Prime committee http://hackage.haskell.org/trac/haskell-prime/wiki/Committee, and ask what the status is, as far as they know. Malcolm asked for proposals at the start of 2011 but I'm not sure if he actually received any, or what happened after that. There are guidelines for representation on the committee, and a process for forming a new committee on that page. The process part depends a bit on the old committee, and I don't know what they feel now that a "gap year" has gone by. But I'm sure they will appreciate your taking a lead in re-booting the process. Don't be put off by the talk of "a committee". This isn't bureaucracy! To revise a community language standard there needs to be a group that leads the process. It needs to be big enough to have a diversity of view, but small enough to make progress. And that's our committee. Simon | -----Original Message----- | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime- | bounces@haskell.org] On Behalf Of Stefan Holdermans | Sent: 02 December 2012 10:24 | To: haskell-prime@haskell.org | Subject: Re: Status of Haskell'? | | Simon wrote: | | > 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! | | | Cheers, | | Stefan | _______________________________________________ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime

I confess that I have not had enough free time in the last two years to have been a good chair for the language committee. (Using Haskell in the real world is just too absorbing!) I think the next chair should probably be an academic, who may have more incentive to spend effort on formalisation of the language design process than us industrial types. (At work, if we want a language extension, we just go ahead and implement it - job done.) There is a mailing list for the members of the language committee: haskell-2011-committee@haskell.org. It has not seen any activity since 3 messages in October 2011, and prior to that, a thread of 13 messages in Nov/December 2010. Both of those threads were largely about the vanishingly small number of proposals to be decided upon, and whether to issue a new Report (the answer being no on both occasions). So, given that there are a few people who have expressed interest in reviving the language formalisation process, perhaps we should hold nominations for a new committee, in the spirit of the method outlined on the wiki page: http://hackage.haskell.org/trac/haskell-prime/wiki/Committee Please send nominations to haskell-2011-committee@haskell.org, summarising your interest and experience. The existing committee will (I hope) make some decision on how to proceed, in early January 2013. Regards, Malcolm On 12 Dec 2012, at 02:42, Ramana Kumar wrote:

Dear Malcolm,

What is the current status of Haskell Prime, as far as you know? (Is there a better way to reach the Haskell Prime committee than just emailing the chair?) We have a few volunteers here looking to keep Haskell Prime moving forward, and Simon suggested following the tracks of earlier pioneers and resuming/joining where they left off.

Cheers, Ramana

On Fri, 28 Dec 2012 02:01:15 +0100, Ramana Kumar wrote:

Hi Malcolm, could you (or someone) help me out with a link to the archives (if any) for this list, and the listinfo page?

http://www.haskell.org/pipermail/haskell-prime/ http://www.haskell.org/mailman/listinfo/haskell-prime Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

Hi Malcolm, On Wed, Dec 12, 2012 at 10:40:53AM +0000, Malcolm Wallace wrote:

Please send nominations to haskell-2011-committee@haskell.org, summarising your interest and experience. The existing committee will (I hope) make some decision on how to proceed, in early January 2013.

Any progress on this? Thanks Ian

On Fri, Feb 01, 2013 at 05:31:53PM +0000, Malcolm Wallace wrote:

The committee has received no nominations.

At least one was sent. Does haskell-2011-committee@haskell.org accept mails from non-members? Thanks Ian