Perhaps we should weigh the +1 and -1s in this thread with the number of lines of Haskell written by the voter? ;) On Mon, Oct 5, 2015 at 5:09 PM, Gershom B wrote:

...

I would like to suggest that the bar for breaking all existing

On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos@serpentine.com) wrote: libraries, books, papers,

...

and lecture notes should be very high; and that the benefit associated with such a breaking change should be correspondingly huge.

My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP.

So the reason for choosing to not do MRP simultaneous with AMP was precisely to allow a gradual migration path where, sans CPP, people could write code compatible with the last three versions of GHC, as the general criteria has been.

So without arguing the necessity or not, I just want to weigh in with a technical opinion that if this goes through, my _estimation_ is that there will be a smooth and relatively painless migration period, the sky will not fall, good teaching material will remain good, those libraries that bitrot will tend to do so for a variety of reasons more significant than this, etc.

It is totally reasonable to have a discussion on whether this change is worth it at all. But let’s not overestimate the cost of it just to further tip the scales :-)

—gershom _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Mon, Oct 5, 2015 at 8:09 AM, Gershom B wrote:

My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

This is a multi-year, "boil the ocean"-style project, affecting literally every Haskell user, and the end result after all of this labor is going to be... a slightly spiffier bike shed? Strongly -1 from me also. My experience over the last couple of years is that every GHC release breaks my libraries in annoying ways that require CPP to fix: ~/personal/src/snap λ find . -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l 64 As a user this is another bikeshedding change that is not going to benefit me at all. Maintaining a Haskell library can be an exasperating exercise of running on a treadmill to keep up with busywork caused by changes to the core language and libraries. My feeling is starting to become that the libraries committee is doing as much (if not more) to *cause* problems and work for me than it is doing to improve the common infrastructure. G -- Gregory Collins

I'm writing a book (http://haskellbook.com/) with my coauthor. It is up to date with GHC 7.10. AMP made things better, not harder, with respect to teaching Haskell. BBP required some explanation of "ignore this type, we're asserting a different one", but the positives are still better than the negatives. Please don't use existing or forthcoming books as an excuse to do or not-do things. Do what's right for the users of the language. On Mon, Oct 5, 2015 at 2:01 PM, Johan Tibell wrote:

On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins wrote:

...

On Mon, Oct 5, 2015 at 8:09 AM, Gershom B wrote:

...

My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one?

This is a multi-year, "boil the ocean"-style project, affecting literally every Haskell user, and the end result after all of this labor is going to be... a slightly spiffier bike shed?

Strongly -1 from me also. My experience over the last couple of years is that every GHC release breaks my libraries in annoying ways that require CPP to fix:

~/personal/src/snap λ find . -name '*.hs' | xargs egrep '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l 64

As a user this is another bikeshedding change that is not going to benefit me at all. Maintaining a Haskell library can be an exasperating exercise of running on a treadmill to keep up with busywork caused by changes to the core language and libraries. My feeling is starting to become that the libraries committee is doing as much (if not more) to *cause* problems and work for me than it is doing to improve the common infrastructure.

On the libraries I maintain and have a copy of on my computer right now: 329

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Chris Allen Currently working on http://haskellbook.com

Dear all, Executive Summary: Please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee While we can discuss the extent of additional breakage MRP would cause, the fact remains it is a further breaking change. A survey of breakage to books as Herbert did is certainly valuable (thanks!), but much breakage will (effectively) remain unquantifiable. It is also clear from the discussions over the last couple of weeks, on the Haskell libraries list as well as various other forums and social media, that MRP is highly contentions. This begs two questions: 1. Is the Haskell Libraries list and informal voting process really an appropriate, or even acceptable, way to adopt such far-reaching changes to what effectively amounts to Haskell itself? 2. Why the hurry to push MRP through? As to question 1, to Graham Hutton's and my knowledge, the libraries list and its voting process was originally set up for 3rd-party libraries in fptools. It seems to have experienced some form of "mission creep" since. Maybe that is understandable given that there was no obvious alternative as HaskellPrime has been defunct for a fair few years. But, as has been pointed out in a number of postings, a lot of people with very valuable perspectives are also very busy, and thus likely to miss a short discussion period (as has happened in the past in relation to the Burning the Bridges proposal) and also have very little time for engaging in long and complicated e-mail discussions that, from their perspective, happen at a completely random point in time and for which they thus have not had a chance to set aside time even if they wanted to participate. Just as one data point, AMP etc. mostly passed Graham and me by simply because a) we were too busy to notice and b) we simply didn't think there was a mandate for such massive overhauls outside of a process like HaskellPrime. And we are demonstrably not alone. This brings us to question 2. Now that HaskellPrime is being resurrected, why the hurry to push MRP through? Surely HaskellPrime is the forum where breaking changes like MRP should be discussed, allowing as much time as is necessary and allowing for an as wide range of perspectives as possible to properly be taken into account? The need to "field test" MRP prior to discussing it in HaskellPrime has been mentioned. Graham and I are very sceptical. In the past, at least in the past leading up to Haskell 2010 or so, the community at large was not roped in as involuntary field testers. If MRP is pushed through now, with a resurrection of HaskellPrime being imminent, Graham and I strongly believe that risks coming across to a very large part of the Haskell community as preempting proper process by facing the new HaskellPrime committee with (yet another) fait accompli. Therefore, please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee, which is where it properly belongs. Otherwise, the Haskell community itself might be one of the things that MRP breaks. Best regards, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

I was always under the impression that +1/-1 was just a quick indicator of opinion, not a vote, and that it was the core libraries committee that would make the final call if enough consensus was reached to enact the change. Erik On 6 October 2015 at 13:32, Henrik Nilsson wrote:

Dear all,

Executive Summary: Please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee

While we can discuss the extent of additional breakage MRP would cause, the fact remains it is a further breaking change. A survey of breakage to books as Herbert did is certainly valuable (thanks!), but much breakage will (effectively) remain unquantifiable.

It is also clear from the discussions over the last couple of weeks, on the Haskell libraries list as well as various other forums and social media, that MRP is highly contentions.

This begs two questions:

1. Is the Haskell Libraries list and informal voting process really an appropriate, or even acceptable, way to adopt such far-reaching changes to what effectively amounts to Haskell itself?

2. Why the hurry to push MRP through?

As to question 1, to Graham Hutton's and my knowledge, the libraries list and its voting process was originally set up for 3rd-party libraries in fptools. It seems to have experienced some form of "mission creep" since. Maybe that is understandable given that there was no obvious alternative as HaskellPrime has been defunct for a fair few years. But, as has been pointed out in a number of postings, a lot of people with very valuable perspectives are also very busy, and thus likely to miss a short discussion period (as has happened in the past in relation to the Burning the Bridges proposal) and also have very little time for engaging in long and complicated e-mail discussions that, from their perspective, happen at a completely random point in time and for which they thus have not had a chance to set aside time even if they wanted to participate.

Just as one data point, AMP etc. mostly passed Graham and me by simply because a) we were too busy to notice and b) we simply didn't think there was a mandate for such massive overhauls outside of a process like HaskellPrime. And we are demonstrably not alone.

This brings us to question 2. Now that HaskellPrime is being resurrected, why the hurry to push MRP through? Surely HaskellPrime is the forum where breaking changes like MRP should be discussed, allowing as much time as is necessary and allowing for an as wide range of perspectives as possible to properly be taken into account?

The need to "field test" MRP prior to discussing it in HaskellPrime has been mentioned. Graham and I are very sceptical. In the past, at least in the past leading up to Haskell 2010 or so, the community at large was not roped in as involuntary field testers.

If MRP is pushed through now, with a resurrection of HaskellPrime being imminent, Graham and I strongly believe that risks coming across to a very large part of the Haskell community as preempting proper process by facing the new HaskellPrime committee with (yet another) fait accompli.

Therefore, please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee, which is where it properly belongs. Otherwise, the Haskell community itself might be one of the things that MRP breaks.

Best regards,

/Henrik

-- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On 10/06/2015 02:06 PM, Erik Hesselink wrote:

I was always under the impression that +1/-1 was just a quick indicator of opinion, not a vote, and that it was the core libraries committee that would make the final call if enough consensus was reached to enact the change.

Ditto. (At the very least for simple +1/-1 posts rather than posts that spell out any particular pros/cons/etc.) Regards,

Hi, Bardur Arantsson wrote:

This is an argument from FUD. If it's unquantifiable then it can (almost by definition) neither count for nor against, can it?

Of course 25 years+ of legacy is there. Quantifiable or not. And of course it must count if we wish Haskell to be taken seriously and be increasingly successful. That is at least the view of a significant part of the Haskell community. And the way to account for it, both that which is quantifiable and that which is not, is to make sure that fundamental language changes are given due consideration in a forum where all stakeholders are adequately represented.

Personally, I don't think there's much need to push the actual *breaking* change through, but I *do* think that deprecation warnings should go in as quickly as possible.

What would the point of that be unless MRP eventually will go through? I am afraid it comes across as an attempt to preempt proper process. I'm somewhat baffled, to say the least.

It seems to me that the community *is* being involved rather than being, as you say, "involuntary field testers".

Well, there are many prominent people who I have not seen posting here. There are others who only found out via facebook postings and the like, alerted by people who like me feel this is not a proper process for a breaking change. The fact that there now is a discussion

As I've certainly mentioned in this thread, the previous committee didn't actually accomplish very much [1].

Measuring "accomplishment" in terms of number of changes seems both naive and worrying to me, I must say. Maybe the committee actually accomplished a great deal by not breaking things unnecessarily, for example?

I also note that much of what they *did* get through was actually mostly already field-tested in GHC beforehand.

But with only a couple of possible exceptions, those were not breaking changes affecting pretty much every single user. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

By comparison, the C++ language -- significantly more complex and affecting a much larger community of users -- has released 4 separate standards in the timeframe between Haskell 98 and now, each of them introducing significant functionality that created work for compiler and tools vendors, users, authors, teachers, and learners. If they can do it, I'm confident we can as well.

C++ never makes any breaking changes.* It has only added things (with the undesirable effect of making the newer and more useful things more verbose than the legacy cruft). [*]: … minus a few rare cases where the features had 0% usage, like 'export templates', so their removal wasn't at all controversial.

On Oct 6, 2015 7:32 AM, "Henrik Nilsson" wrote:

Executive Summary: Please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee

Many more people are on this mailing list than will be chosen for the committee. Those who are not chosen have useful perspectives as well.

1. Is the Haskell Libraries list and informal voting process really an appropriate, or even acceptable, way to adopt such far-reaching changes to what effectively amounts to Haskell itself?

As others have said, no one wants that.

But, as has been pointed out in a number of postings, a lot of people with very valuable perspectives are also very busy, and thus likely to miss a short discussion period (as has happened in the past in relation to the Burning the Bridges proposal)

The Foldable/Traversable BBP indeed was not as well discussed as it should have been. AMP, on the other hand, was discussed extensively and publicly for months. I understand that some people need months of notice to prepare to participate in a discussion. Unfortunately, I don't think those people can always be included. Life moves too quickly for that. I do think it might be valuable to set up a moderated, extremely low volume mailing list for discussion of only the most important changes, with its messages forwarded to the general list.

The need to "field test" MRP prior to discussing it in HaskellPrime has been mentioned. Graham and I are very sceptical. In the past, at least in the past leading up to Haskell 2010 or so, the community at large was not roped in as involuntary field testers.

No, and Haskell 2010 was, by most measures, a failure. It introduced no new language features (as far as I can recall) and only a few of the most conservative library changes imaginable. Standard Haskell has stagnated since 1998, 17 years ago. Haskell 2010 did not reflect the Haskell people used in their research our practical work then, and I think people are justified in their concern that the next standard may be similarly disappointing. One of the major problems is the (understandable, and in many ways productive) concentration of development effort in a single compiler. When there is only one modern Haskell implementation that is commonly used, it's hard to know how changes to the standard will affect other important implementation techniques, and therefore hard to justify any substantial changes. That was true in 2010, and it is, if anything, more true now.

Therefore, please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee, which is where it properly belongs. Otherwise, the Haskell community itself might be one of the things that MRP breaks.

I hope not. Haskell has gained an awful lot from the researchers, teachers, and developers who create it and use it. I hope we can work out an appropriate balance of inclusion, caution, and speed.

On 5 October 2015 at 20:58, Sven Panne wrote:

2015-10-05 17:09 GMT+02:00 Gershom B :

...

[...] As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP. [...]

Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is now part of the Prelude, you can't simply import some compatibility module, because GHC might tell you (rightfully) that that import is redundant, because (<$>) is already visible through the Prelude. So you'll have to use CPP to avoid that import on base >= 4.8, be it from it Data.Functor, Control.Applicative or some compat-* module. And you'll have to use CPP in each and every module using <$> then, unless I miss something obvious. AFAICT all transitioning guides ignore -Wall and friends...

Does the hack mentioned on the GHC trac [1] work for this? It seems a bit fragile but that page says it works and it avoids CPP. Erik [1] https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimportof...is...

Sven Panne writes:

If you take e.g. (<$>) which is now part of the Prelude, you can't simply import some compatibility module, because GHC might tell you (rightfully) that that import is redundant, because (<$>) is already visible through the Prelude.

Yes, the proper solution is slightly more complicated than just importing Prelude.Compat [1]. You also have to specify "import Prelude ()" -- or compile with NoImplicitPrelude, if you prefer that kind of thing. Best regards Peter [1] http://hackage.haskell.org/package/base-compat-0.8.2/docs/Prelude-Compat.htm...

It might be enough to just add a NOWARN <warning type> pragma that acts on a single line/expression. I've seen it in both C++ and Python linters and it works reasonably well and it's quite general. On Tue, Oct 6, 2015 at 10:44 AM, Ben Gamari wrote:

Sven Panne writes:

...

2015-10-05 17:09 GMT+02:00 Gershom B :

...

On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos@serpentine.com ) wrote: [...] As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP. [...]

Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is now part of the Prelude, you can't simply import some compatibility module, because GHC might tell you (rightfully) that that import is redundant, because (<$>) is already visible through the Prelude. So you'll have to use CPP to avoid that import on base >= 4.8, be it from it Data.Functor, Control.Applicative or some compat-* module. And you'll have to use CPP in each and every module using <$> then, unless I miss something obvious. AFAICT all transitioning guides ignore -Wall and friends...

This is a fair point that comes up fairly often. The fact that CPP is required to silence redundant import warnings is quite unfortunate. Others languages have better stories in this area. One example is Rust, which has a quite flexible `#[allow(...)]` pragma which can be used to acknowledge and silence a wide variety of warnings and lints [1].

I can think of a few ways (some better than others) how we might introduce a similar idea for import redundancy checks in Haskell,

1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,

-- in Control.Applicative {-# ALLOW redundant_import (<$>) #-} (<$>) :: (a -> b) -> f a -> f b (<$>) = fmap

asking the compiler to pretend that any import of the symbol did not exist when looking for redundant imports. This would allow library authors to appropriately mark definitions when they are moved, saving downstream users from having to make any change whatsoever.

2. Or alternatively we could make this a idea a bit more precise,

-- in Control.Applicative {-# ALLOW redundant_import Prelude.(<$>) #-} (<$>) :: (a -> b) -> f a -> f b (<$>) = fmap

Which would ignore imports of `Control.Applicative.(<$>)` only if `Prelude.(<$>)` were also in scope.

3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import,

import {-# ALLOW redundant_import #-} Control.Applicative

-- or perhaps import Control.Applicative {-# ALLOW redundant_import Control.Applicative #-}

allowing the user to explicitly state that they are aware that this import may be redundant.

4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an import list,

import Control.Applicative ((<$>) {-# ALLOW redundant_import #-})

allowing the user to explicitly state that they are aware that this imported function may be redundant.

In general I'd like to reiterate that many of the comments in this thread describe genuine sharp edges in our language which have presented a real cost in developer time during the AMP and and FTP transitions. I think it is worth thinking of ways to soften these edges; we may be surprised how easy it is to fix some of them.

- Ben

[1] https://doc.rust-lang.org/stable/reference.html#lint-check-attributes

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Tue, Oct 6, 2015 at 6:16 PM, Bardur Arantsson wrote:

On 10/06/2015 11:11 AM, Johan Tibell wrote:

...

It might be enough to just add a NOWARN <warning type> pragma that acts on a single line/expression. I've seen it in both C++ and Python linters and it works reasonably well and it's quite general.

+1. Simple is good and can hopefully also be backported to older GHC releases. (Provided someone's willing to do said releases, obviously.)

I've thought of this in the past and it would be great to have. Another possible use case is to allow this for extensions as well, e.g. "Only allow UndecidableInstances for this declaration"

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On Tue, Oct 6, 2015 at 4:44 AM, Ben Gamari wrote:

Sven Panne writes:

...

2015-10-05 17:09 GMT+02:00 Gershom B :

...

On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos@serpentine.com ) wrote: [...] As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP. [...]

Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is now part of the Prelude, you can't simply import some compatibility module, because GHC might tell you (rightfully) that that import is redundant, because (<$>) is already visible through the Prelude. So you'll have to use CPP to avoid that import on base >= 4.8, be it from it Data.Functor, Control.Applicative or some compat-* module. And you'll have to use CPP in each and every module using <$> then, unless I miss something obvious. AFAICT all transitioning guides ignore -Wall and friends...

This is a fair point that comes up fairly often. The fact that CPP is required to silence redundant import warnings is quite unfortunate. Others languages have better stories in this area. One example is Rust, which has a quite flexible `#[allow(...)]` pragma which can be used to acknowledge and silence a wide variety of warnings and lints [1].

I can think of a few ways (some better than others) how we might introduce a similar idea for import redundancy checks in Haskell,

1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition,

-- in Control.Applicative {-# ALLOW redundant_import (<$>) #-} (<$>) :: (a -> b) -> f a -> f b (<$>) = fmap

asking the compiler to pretend that any import of the symbol did not exist when looking for redundant imports. This would allow library authors to appropriately mark definitions when they are moved, saving downstream users from having to make any change whatsoever.

2. Or alternatively we could make this a idea a bit more precise,

-- in Control.Applicative {-# ALLOW redundant_import Prelude.(<$>) #-} (<$>) :: (a -> b) -> f a -> f b (<$>) = fmap

Which would ignore imports of `Control.Applicative.(<$>)` only if `Prelude.(<$>)` were also in scope.

One obvious solution I haven't seen mentioned is the ability to add nonexistent identifier to a hiding clause (these identifiers might presumably exist in some other version of the import): import Prelude hiding ((<$>)) I can see the argument for marking such imports with a pragma, though it gets a bit ugly. -Jan-Willem Maessen

Hi all, Geoffrey Mainland wrote;

What worries me most is that we have started to see very valuable members of our community publicly state that they are reducing their community involvement.

That worries me too. A lot. To quote myself from an earlier e-mail in this thread:

Therefore, please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee, which is where it properly belongs. Otherwise, the Haskell community itself might be one of the things that MRP breaks.

Geoffrey further wrote:

Proposal 3: A decision regarding any proposal that significantly affects backwards compatibility is within the purview of the Haskell Prime Committee, not the Core Libraries Committee.

I thus definitely support this, at least for anything related to the libraries covered by the Haskell report. Indeed, I strongly suspect that many people who did not actively follow the libraries discussions did so because they simply did not think that changes to the central libraries as defined in the Haskell report, at least not breaking changes, were in the remit of the libraries committee, and were happy to leave discussions on any other libraries to the users of those libraries. And as a consequence they were taken by surprise by AMP etc. So before breaking anything more, that being code, research papers, books, what people have learned, or even the community itself, it is time to very carefully think about what the appropriate processes should be for going forward. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

Hi all, Jeremy wrote:

There seems to be a fair amount of friction between those who want to introduce new features or fix significant historical warts in the base libraries - even if this requires breaking changes - and those who insist on no significant breaking changes in new releases, regardless of the reason or how much warning was given.

With respect, and without commenting on the merits of the proposal that is then outlined (Long-Term Support Haskell), I don't think this is an accurate description of the two main positions in the debate at all. Most of those who have argued against MRP, for example, have made it very clear that they are not at all against any breaking change. But they oppose breaking changes to Haskell itself, including central libraries, as defined by the Haskell report, unless the benefits are very compelling indeed. Speaking for myself, I have had to clarify this position a number of times now, as there has been a tendency by the some proponents of the proposed changes to suggest that those who disagree are against all changes, the long term implication being that Haskell would "stagnate and die". And in the light of the above, I felt compelled to clarify this position again. It's not about no more changes ever. It is about ensuring that changes are truly worthwhile and have wide support. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

Friends I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future. Geoff's message had some good ideas, especially this bit: | Proposal 2: After a suitable period of discussion on the libraries list, the | Core Libraries Committee will summarize the arguments for and against a | proposal and post it, along with a (justified) preliminary decision, to a | low-traffic, announce-only email list. After another suitable period of | discussion, they will issue a final decision. What is a suitable period of | time? Perhaps that depends on the properties of the proposal, such as | whether it breaks backwards compatibility. Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing. I believe that the Core Libraries committee is thinking actively about this. | Personally, I think AMP was the right thing to do, but I don't think FTP was | the right thing. These make good examples to motivate future changes to our process. But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above. We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction. In a big community, even a broad consultation may yield a result that some think is ill-advised. That's part of the joyful burden of being a big community. Let's look forward, not back. I think we can do better in future than we have done in the past. I don't think we can hope for unanimity, but I think we can reasonably seek * transparency; * clarity about what decisions are on the table; * broad consultation about decisions that affect a broad constituency; and * a decent opportunity to debate them without having to be involved in massive email threads. Let's try do to that. Simon PS: For what it's worth I'm less keen on Geoff's other proposal: | Proposal 3: A decision regarding any proposal that significantly affects | backwards compatibility is within the purview of the Haskell Prime | Committee, not the Core Libraries Committee. *Precisely* the same issues will arise whether it's CLC or HPC. And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.

I'd also like to raise my concerns about an LTS solution. #1 incremental change is far more consumable than large blocks of change. We all know the fable of python 3, perl 6, etc. #2 One concern that has been voiced by departing maintainers is the burden of maintaining compatibility. An LTS strategy only increases this burden by extending dead code paths. On Oct 21, 2015 10:43 AM, "Geoffrey Mainland" wrote:

...

Friends

I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future. Geoff's message had some good ideas, especially this bit:

| Proposal 2: After a suitable period of discussion on the libraries

...

| Core Libraries Committee will summarize the arguments for and against a | proposal and post it, along with a (justified) preliminary decision, to a | low-traffic, announce-only email list. After another suitable period of | discussion, they will issue a final decision. What is a suitable

...

| time? Perhaps that depends on the properties of the proposal, such as | whether it breaks backwards compatibility.

Identifying major changes to the libraries, and having a better

On 10/21/2015 07:30 AM, Simon Peyton Jones wrote: list, the period of publicised, more RFC-like process for deliberating them, would be a good thing. I believe that the Core Libraries committee is thinking actively about this.

...

| Personally, I think AMP was the right thing to do, but I don't think

...

| the right thing.

These make good examples to motivate future changes to our process. But in the end FTP was subject to a pretty broad deliberative process,

FTP was precisely along the lines that Geoff suggests above. We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction. In a big community, even a broad consultation may yield a result that some think is ill-advised. That's part of the joyful burden of being a big community.

...

Let's look forward, not back. I think we can do better in future than

we have done in the past. I don't think we can hope for unanimity, but I think we can reasonably seek

...

* transparency; * clarity about what decisions are on the table; * broad consultation about decisions that affect a broad constituency; and * a decent opportunity to debate them without having to be involved in massive email threads. Let's try do to that.

Simon

PS: For what it's worth I'm less keen on Geoff's other proposal:

| Proposal 3: A decision regarding any proposal that significantly

affects

...

| backwards compatibility is within the purview of the Haskell Prime | Committee, not the Core Libraries Committee.

*Precisely* the same issues will arise whether it's CLC or HPC. And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.

For the record, I am also not sure Proposal 3 is a good idea :)

However, I do think we could clarify what the respective responsibilities of the core libraries committee and Haskell Prime committees are.

One possible choice is that the core libraries committee is responsible for changes to the core libraries that do not affect libraries in the report. It is meant to be nimble, able to quickly deal with the large volume of library changes that do not impact backwards compatibility.

In this scenario, the Haskell Prime committee, using a longer deliberative process, would consider the more impactful library changes and batch them up into new reports.

You are absolutely correct that moving the question to the Haskell Prime committee risks pushing the issue around. The idea behind the separation outlined above is to reduce the treadmill; the two bodies use different processes, with different time frames, to arrive at decisions. Some library decisions may deserve a longer deliberative process.

Cheers, Geoff _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Hello, I'm Dan Doel. I'm on the core libraries committee (though I'm speaking only for myself). As I recall, one of the reasons I got tapped for it was due to my having some historical knowledge about Haskell; not because I was there, but because I've gone back and looked at some old reports and whatnot (and sometimes think they're better than what we have now). But, I was around (of course) when the core libraries committee started up, so perhaps I can play the role of historian for this as well. The reason the committee exists is because a couple years ago, people brought up the ideas that were finally realized in the Applicative-Monad proposal and the Foldable-Traversable proposal. A lot of people weighed in saying they thought they were a good idea, and significantly fewer people weighed in saying they thought that it shouldn't happen for various reasons---roughly the same things that people are still bringing up about these proposals. This wasn't the first time that happened, either. I think it was widely agreed among most users that Functor should be a superclass of Monad since I started learning Haskell around 10 years ago. And once Applicative was introduced, it was agreed that that should go in the middle of the two. But it appeared that it would never happen, despite a significant majority thinking it should, because no one wanted to do anything without pretty much unanimous consent. So, one question that got raised is: why should this majority of people even use Haskell/GHC anymore? Why shouldn't they start using some other language that will let them change 15-year-old mistakes, or adapt to ideas that weren't even available at that time (but are still fairly old and established, all things considered). And the answer was that there should be some body empowered to decide to move forward with these ideas, even if there is some dissent. And frankly, it wasn't going to be the prime committee, because it hadn't shown any activity in something like 3 years at the time, and even when it was active, it didn't make anywhere near the sort of changes that were being discussed. And the kicker to me is, many things that people are complaining about again (e.g. the FTP) were the very things that the committee was established to execute. I don't think we had a formal vote on that proposal, because we didn't need to. Our existence was in part to execute that proposal (and AMP). And then a year ago, when it was finally time to release the changes, there was another ruckus. And we still didn't have a CLC vote on the matter. What we did was conduct a community poll, and then SPJ reviewed the submissions. But I don't mean to pass the buck to him, because I'm pretty sure he was worried that we were crazy, and overstepping our bounds. Just, the results of the survey were sufficient for him to not overrule us. So my point is this: there seems to be some sentiment that the core libraries committee is unsound, and making bad decisions. But the complaints are mostly not even about actual decisions we made (aside from maybe Lennart Augustsson's, where he is unhappy with details of the FTP that you can blame on us, but were designed to break the least code, instead of being the most elegant; if we had pleased him more, we would have pleased others less). They are about the reasons for founding the committee in the first place. You can blame us, if you like, because I think it's certain that we would have approved them if we had formally voted. We just didn't even need to do so. Forgive me if I'm wrong, but suggestions that these decisions should have been deferred to a Haskell Prime committee mean, to me, that the hope is that they would have been rejected. That the Haskell Prime committee should have just vetoed these proposals that something like 80% or more of practicing Haskell users (as far as we can tell) wanted for years before they finally happened. That the Haskell Prime committee should be responsible for enforcing the very status quo that led to the CLC in the first place, where proposals with broad support but minority dissent never pass for various core modules. If this is the case, then one could simply repose the earlier question: why should most of these people stick around to obey by the Haskell Prime committee's pronouncements, instead of getting to work on a language that incorporates their input? And if it isn't, then I don't ultimately understand what the complaints are. We try to accomplish the (large) changes in a manner that allows transition via refactoring over multiple versions (and as I mentioned earlier, some complaints are that we compromised _too much_ for this). And in light of the more recent complaints, it's even been decided that our time frames should be longer. Rolling up changes into a report just seems like it makes transitions less smooth. Unless the idea is to make GHC capable of switching out entire base library sets; but someone has to implement that, and once you have it, it makes the report specifications _less_ essential. Anyhow, that's my history lesson. Take it as you (all) will. Cheers, -- Dan On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland wrote:

On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:

...

Friends

I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future. Geoff's message had some good ideas, especially this bit:

| Proposal 2: After a suitable period of discussion on the libraries list, the | Core Libraries Committee will summarize the arguments for and against a | proposal and post it, along with a (justified) preliminary decision, to a | low-traffic, announce-only email list. After another suitable period of | discussion, they will issue a final decision. What is a suitable period of | time? Perhaps that depends on the properties of the proposal, such as | whether it breaks backwards compatibility.

Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing. I believe that the Core Libraries committee is thinking actively about this.

| Personally, I think AMP was the right thing to do, but I don't think FTP was | the right thing.

These make good examples to motivate future changes to our process. But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above. We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction. In a big community, even a broad consultation may yield a result that some think is ill-advised. That's part of the joyful burden of being a big community.

Let's look forward, not back. I think we can do better in future than we have done in the past. I don't think we can hope for unanimity, but I think we can reasonably seek

* transparency; * clarity about what decisions are on the table; * broad consultation about decisions that affect a broad constituency; and * a decent opportunity to debate them without having to be involved in massive email threads. Let's try do to that.

Simon

PS: For what it's worth I'm less keen on Geoff's other proposal:

| Proposal 3: A decision regarding any proposal that significantly affects | backwards compatibility is within the purview of the Haskell Prime | Committee, not the Core Libraries Committee.

*Precisely* the same issues will arise whether it's CLC or HPC. And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it.

For the record, I am also not sure Proposal 3 is a good idea :)

However, I do think we could clarify what the respective responsibilities of the core libraries committee and Haskell Prime committees are.

One possible choice is that the core libraries committee is responsible for changes to the core libraries that do not affect libraries in the report. It is meant to be nimble, able to quickly deal with the large volume of library changes that do not impact backwards compatibility.

In this scenario, the Haskell Prime committee, using a longer deliberative process, would consider the more impactful library changes and batch them up into new reports.

You are absolutely correct that moving the question to the Haskell Prime committee risks pushing the issue around. The idea behind the separation outlined above is to reduce the treadmill; the two bodies use different processes, with different time frames, to arrive at decisions. Some library decisions may deserve a longer deliberative process.

Cheers, Geoff _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

While we are here, let me say A BIG THANK YOU TO THE CORE LIBRARIES COMMITTEE Library design has a lot of detail, and a lot of competing priorities. I am personally very grateful to the CLC for the work they put into this. Like many crucial tasks it's one that often seems to attract more complaints than thanks, but they are doing us all a huge service, and at significant cost in terms of their most precious and inelastic commodity: their personal time. Remember, as Dan says, before the CLC we no process whatsoever for library evolution... various people made various patches, and there was no way of getting anything substantial done. So we are far far further on than before. Still not perfect, as my last post said. But still: THANK YOU. Simon | -----Original Message----- | From: Dan Doel [mailto:dan.doel@gmail.com] | Sent: 21 October 2015 22:23 | To: Geoffrey Mainland | Cc: Simon Peyton Jones; Augustsson, Lennart; Henrik Nilsson; haskell- | prime@haskell.org List; Haskell Libraries | Subject: Re: Breaking Changes and Long Term Support Haskell | | Hello, | | I'm Dan Doel. I'm on the core libraries committee (though I'm speaking | only for myself). As I recall, one of the reasons I got tapped for it | was due to my having some historical knowledge about Haskell; not | because I was there, but because I've gone back and looked at some old | reports and whatnot (and sometimes think they're better than what we | have now). | | But, I was around (of course) when the core libraries committee | started up, so perhaps I can play the role of historian for this as | well. | | The reason the committee exists is because a couple years ago, people | brought up the ideas that were finally realized in the | Applicative-Monad proposal and the Foldable-Traversable proposal. A | lot of people weighed in saying they thought they were a good idea, | and significantly fewer people weighed in saying they thought that it | shouldn't happen for various reasons---roughly the same things that | people are still bringing up about these proposals. | | This wasn't the first time that happened, either. I think it was | widely agreed among most users that Functor should be a superclass of | Monad since I started learning Haskell around 10 years ago. And once | Applicative was introduced, it was agreed that that should go in the | middle of the two. But it appeared that it would never happen, despite | a significant majority thinking it should, because no one wanted to do | anything without pretty much unanimous consent. | | So, one question that got raised is: why should this majority of | people even use Haskell/GHC anymore? Why shouldn't they start using | some other language that will let them change 15-year-old mistakes, or | adapt to ideas that weren't even available at that time (but are still | fairly old and established, all things considered). And the answer was | that there should be some body empowered to decide to move forward | with these ideas, even if there is some dissent. And frankly, it | wasn't going to be the prime committee, because it hadn't shown any | activity in something like 3 years at the time, and even when it was | active, it didn't make anywhere near the sort of changes that were | being discussed. | | And the kicker to me is, many things that people are complaining about | again (e.g. the FTP) were the very things that the committee was | established to execute. I don't think we had a formal vote on that | proposal, because we didn't need to. Our existence was in part to | execute that proposal (and AMP). And then a year ago, when it was | finally time to release the changes, there was another ruckus. And we | still didn't have a CLC vote on the matter. What we did was conduct a | community poll, and then SPJ reviewed the submissions. But I don't | mean to pass the buck to him, because I'm pretty sure he was worried | that we were crazy, and overstepping our bounds. Just, the results of | the survey were sufficient for him to not overrule us. | | So my point is this: there seems to be some sentiment that the core | libraries committee is unsound, and making bad decisions. But the | complaints are mostly not even about actual decisions we made (aside | from maybe Lennart Augustsson's, where he is unhappy with details of | the FTP that you can blame on us, but were designed to break the least | code, instead of being the most elegant; if we had pleased him more, | we would have pleased others less). They are about the reasons for | founding the committee in the first place. You can blame us, if you | like, because I think it's certain that we would have approved them if | we had formally voted. We just didn't even need to do so. | | Forgive me if I'm wrong, but suggestions that these decisions should | have been deferred to a Haskell Prime committee mean, to me, that the | hope is that they would have been rejected. That the Haskell Prime | committee should have just vetoed these proposals that something like | 80% or more of practicing Haskell users (as far as we can tell) wanted | for years before they finally happened. That the Haskell Prime | committee should be responsible for enforcing the very status quo that | led to the CLC in the first place, where proposals with broad support | but minority dissent never pass for various core modules. | | If this is the case, then one could simply repose the earlier | question: why should most of these people stick around to obey by the | Haskell Prime committee's pronouncements, instead of getting to work | on a language that incorporates their input? | | And if it isn't, then I don't ultimately understand what the | complaints are. We try to accomplish the (large) changes in a manner | that allows transition via refactoring over multiple versions (and as | I mentioned earlier, some complaints are that we compromised _too | much_ for this). And in light of the more recent complaints, it's even | been decided that our time frames should be longer. Rolling up changes | into a report just seems like it makes transitions less smooth. Unless | the idea is to make GHC capable of switching out entire base library | sets; but someone has to implement that, and once you have it, it | makes the report specifications _less_ essential. | | Anyhow, that's my history lesson. Take it as you (all) will. | | Cheers, | -- Dan | | On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland | wrote: | > On 10/21/2015 07:30 AM, Simon Peyton Jones wrote: | >> Friends | >> | >> I think it's good for us to debate the question of how we should | balance innovation against change; and how we should make those decisions | in future. Geoff's message had some good ideas, especially this bit: | >> | >> | Proposal 2: After a suitable period of discussion on the libraries | list, the | >> | Core Libraries Committee will summarize the arguments for and | against a | >> | proposal and post it, along with a (justified) preliminary decision, | to a | >> | low-traffic, announce-only email list. After another suitable period | of | >> | discussion, they will issue a final decision. What is a suitable | period of | >> | time? Perhaps that depends on the properties of the proposal, such | as | >> | whether it breaks backwards compatibility. | >> | >> Identifying major changes to the libraries, and having a better | publicised, more RFC-like process for deliberating them, would be a good | thing. I believe that the Core Libraries committee is thinking actively | about this. | >> | >> | Personally, I think AMP was the right thing to do, but I don't think | FTP was | >> | the right thing. | >> | >> These make good examples to motivate future changes to our process. | But in the end FTP was subject to a pretty broad deliberative process, | precisely along the lines that Geoff suggests above. We had two clearly- | articulated alternatives, a discrete call for opinions broadcast to every | Haskell channel we could find, a decent interval for people to respond, | and (as it turned out) a very clear preponderance of opinion in one | direction. In a big community, even a broad consultation may yield a | result that some think is ill-advised. That's part of the joyful burden | of being a big community. | >> | >> Let's look forward, not back. I think we can do better in future than | we have done in the past. I don't think we can hope for unanimity, but I | think we can reasonably seek | >> | >> * transparency; | >> * clarity about what decisions are on the table; | >> * broad consultation about decisions that affect | >> a broad constituency; and | >> * a decent opportunity to debate them without having | >> to be involved in massive email threads. Let's try do to that. | >> | >> Simon | >> | >> PS: For what it's worth I'm less keen on Geoff's other proposal: | >> | >> | Proposal 3: A decision regarding any proposal that significantly | affects | >> | backwards compatibility is within the purview of the Haskell Prime | >> | Committee, not the Core Libraries Committee. | >> | >> *Precisely* the same issues will arise whether it's CLC or HPC. And | the HPC is going to be jolly busy with language issues. Moving the | question from one group to another risks avoiding the issue rather than | addressing it. | > | > For the record, I am also not sure Proposal 3 is a good idea :) | > | > However, I do think we could clarify what the respective | > responsibilities of the core libraries committee and Haskell Prime | > committees are. | > | > One possible choice is that the core libraries committee is responsible | > for changes to the core libraries that do not affect libraries in the | > report. It is meant to be nimble, able to quickly deal with the large | > volume of library changes that do not impact backwards compatibility. | > | > In this scenario, the Haskell Prime committee, using a longer | > deliberative process, would consider the more impactful library changes | > and batch them up into new reports. | > | > You are absolutely correct that moving the question to the Haskell Prime | > committee risks pushing the issue around. The idea behind the separation | > outlined above is to reduce the treadmill; the two bodies use different | > processes, with different time frames, to arrive at decisions. Some | > library decisions may deserve a longer deliberative process. | > | > Cheers, | > Geoff | > _______________________________________________ | > Libraries mailing list | > Libraries@haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske | ll.org%2fcgi- | bin%2fmailman%2flistinfo%2flibraries&data=01%7c01%7csimonpj%40064d.mgd.mic | rosoft.com%7c6e0a5cbb4f5541caf14108d2da5dc7f8%7c72f988bf86f141af91ab2d7cd0 | 11db47%7c1&sdata=zL3zfXigvfpvdXL%2bhWuGoQzUUhGp%2bg8ofO1tGaFzlvE%3d

On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland wrote:

My original email stated my underlying concern: we are losing valuable members of the community not because of the technical decisions that are being made, but because of the process by which they are being made.

I disagree. The issue is not process, it's posture: e.g. what do we think the language is for, who are its users, what factors do we take into consideration when making decisions about how to change things (and especially: how do we weight those factors), etc. There are several important constituencies within the Haskell community, and they usually have very different attitudes towards what's relevant to take into consideration when deciding what to do. For example: Haskell has had great success and wide adoption in academic research within a few fields centred around ICFP, POPL, and the like. We all like a GHC that serves as a testbed for research and sometimes that is going to mean churn. The research world would probably be happiest with a Haskell that evolved quickly and speculatively, and that dispensed with blemishes with savage efficiency: if you're doing research you're on the treadmill, almost by definition, and you're delighted that we're finally making some rapid progress on fixing up some of the longstanding warts. If you're a practitioner, you are interested in using Haskell for, y'know, writing programs. You're probably in one of two camps: you're in "green field" mode writing a lot of new code (early stage startups, prototype work, etc), or you're maintaining/extending programs you've already written that are out "in the field" for you doing useful work. Laura Wingerd calls this the "annealing temperature" of software, and I think this is a nice metaphor to describe it. How tolerant you are of ecosystem churn depends on what your temperature is: and I think it should be obvious to everyone that Haskell having "success" for programming work would mean that lots of useful and correct programs get written, so everyone who is in the former camp will cool over time to join the latter. I've made the point before and I don't really want to belabor it: our de facto collective posture towards breaking stuff, especially in the past few years, has been extremely permissive, and this alienates people who are maintaining working programs. I'm actually firmly of the belief that the existing committee doesn't really have process issues, and in fact, that often it's been pretty careful to minimize the impact of the changes it wants to make. As others have pointed out, lots of the churn actually comes from platform libraries, which are out of the purview of this group. All I'm saying is that if we want to appeal to or cater to working software engineers, we have to be a lot less cavalier about causing more work for them, and we need to prize stability of the core infrastructure more highly. That'd be a broader cultural change, and that goes beyond process: it's policy. -- Gregory Collins

On Thu, Oct 22, 2015 at 2:04 AM, Taru Karttunen wrote:

E.g. if

A) Most of Hackage (including dependencies) compiles with new GHC. (stack & stackage helps somewhat)

B) There is an automated tool that can be used to fix most code to compile with new versions of GHC without warnings or CPP.

C) Hackage displays vocally what works with which versions of GHC (Status reports do help somewhat)

Then I think much of the complaints would go away.

If we had those things, indeed they would! However, beyond A (GHC 7.10 was tested more extensively against hackage/stackage than any previous release of Haskell by far!), the others require various degrees of engineering effort, including some way to deal with refactoring code that already has CPP in it, more extensive build-bot services, etc. and those sort of non-trivial artifacts just haven't been forthcoming. =/ I would be very happy if those things showed up, however. -Edward

On 22.10 09:04, Herbert Valerio Riedel wrote:

Fyi, Alan is currently working on levaraging HaRe[1] in

https://github.com/alanz/Hs2010To201x (the `parsing-only` branch)

and it's already showing great promise. However, tools like this will only be able to handle the no-brainer cases, as in general it's a NP hard problem. But luckily, those boring mechanical refactorings usually represent the vast majority, and that's the tedious work we want tooling to assist us most with.

Yes, getting it 99% there as an automated tool would be enough for most cases.

...

C) Hackage displays vocally what works with which versions of GHC (Status reports do help somewhat)

I.e. something like

http://matrix.hackage.haskell.org/package/text

Yes! Is there a reason that it is not displayed on http://hackage.haskell.org/package/text which only displays a link to Status of a 7.8.3 build? How many percent of Hackage is built with matrix.h.h.o and is there a plan to integrate it into Hackage pages? - Taru Karttunen

On 10/22/2015 02:40 AM, Edward Kmett wrote:

On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins mailto:greg@gregorycollins.net> wrote:

On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland mailto:mainland@apeiron.net> wrote:

My original email stated my underlying concern: we are losing valuable members of the community not because of the technical decisions that are being made, but because of the process by which they are being made.

[If] you're doing research you're on the treadmill, almost by definition, and you're delighted that we're finally making some rapid progress on fixing up some of the longstanding warts.

If you're a practitioner, you are interested in using Haskell for, y'know, writing programs. You're probably in one of two camps: you're in "green field" mode writing a lot of new code (early stage startups, prototype work, etc), or you're maintaining/extending programs you've already written that are out "in the field" for you doing useful work. Laura Wingerd calls this the "annealing temperature" of software, and I think this is a nice metaphor to describe it. How tolerant you are of ecosystem churn depends on what your temperature is: and I think it should be obvious to everyone that Haskell having "success" for programming work would mean that lots of useful and correct programs get written, so everyone who is in the former camp will cool over time to join the latter.

I've made the point before and I don't really want to belabor it: our de facto collective posture towards breaking stuff, especially in the past few years, has been extremely permissive, and this alienates people who are maintaining working programs.

Even among people who purported to be teaching Haskell or using Haskell today in industry the margin of preference for the concrete FTP proposal was ~79%. This was considerably higher than I expected in two senses. One: there were a lot more people who claimed to be in one of those two roles than I expected by far, and two: their appetite for change was higher than I expected. I initially expected to see a stronger "academic vs. industry" split in the poll, but the groups were only distinguishable by a few percentage point delta, so while I expected roughly the end percentage of the poll, based on the year prior I'd spent running around the planet to user group meetings and the like, I expected it mostly because I expected more hobbyists and less support among industrialists.

I'm actually firmly of the belief that the existing committee doesn't really have process issues, and in fact, that often it's been pretty careful to minimize the impact of the changes it wants to make. As others have pointed out, lots of the churn actually comes from platform libraries, which are out of the purview of this group.

Historically we've had a bit of a split personality on this front. Nothing that touches the Prelude had changed in 17 years. On the other hand the platform libraries had maintained a pretty heavy rolling wave of breakage the entire time I've been around in the community. On a more experimental feature front, I've lost count of the number of different things we've done to Typeable or template-haskell.

All I'm saying is that if we want to appeal to or cater to working software engineers, we have to be a lot less cavalier about causing more work for them, and we need to prize stability of the core infrastructure more highly. That'd be a broader cultural change, and that goes beyond process: it's policy.

The way things are shaping up, we've had 17 years of rock solid stability, 1 release that incorporated changes that were designed to minimize impact, to the point that the majority of the objections against them are of the form where people would prefer that we broke _more_ code, to get a more sensible state. Going forward, it looks like the next 2 GHC releases will have basically nothing affecting the Prelude, and there will be another punctuation in the equilibrium around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That gives 2 years worth of advance notice of pending changes, and a pretty strong guarantee from the committee that you should be able to maintain code with a 3 release window without running afoul of warnings or needing CPP.

So, out of curiosity, what additional stability policy is it that you seek?

Thanks to you and Dan [1], I now have a greater understanding and appreciation for where the committee has been coming from. My new understanding is that the changes that were formalized in AMP, FTP, and MRP were the basis for the committee's creation. It also seems that there are more changes in the pipeline that have not yet been made into proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of "stability" is signaling change as far ahead as possible. The committee has put a lot of effort into this, which I appreciate! However, as each of these proposal has come down the pipeline, I never realized that they were part of a larger master plan. 1) What is the master plan, and where is it documented, even if this document is not up to the standard of a proposal? What is the final target, and when might we expect it to be reached? What is in the pipeline after MRP? Relatedly, guidance on how to write code now so that it will be compatible with future changes helps mitigate the stability issue. 2) How can I write code that makes use of the Prelude so that it will work with every new GHC release over the next 3 years? 5 years? For example, how can I write a Monad instance now, knowing the changes that are coming, so that the instance will work with every new GHC release for the next 3 years? 5 years? If the answer is "you can't," then when might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to say I don't know the answer! Finally, if none of these changes broke Prelude backwards compatibility, far fewer people would be complaining :) Of course, we can't always make progress without breaking things, but a more deliberative process might offer an opportunity to make progress while still preserving backwards compatibility. Take AMP for example. There were at least two [3] [4] proposals for preserving backwards compatibility. Investigating them would have taken time and delayed AMP, yes, but why the rush? 3) Can we have a process that allows more deliberation over, and wider publicity for, changes that break backwards compatibility? The goal of such a process would not be to prevent change, but to allow more time to find possible solution to the issue of backwards compatibility. My proposal for a low-traffic mailing list where all proposals were announced was meant to provide wider publicity. Personally, I think these proposals do indeed fix a lot of warts in the language. As a researcher who uses actively uses Haskell every day, these warts have had approximately zero impact on me for the past (almost) decade, and I would be perfectly content if they were never fixed. The only pain I can recall enduring is having to occasionally write an orphan Applicative instance. I have been importing Prelude hiding mapM for years. I have been importing Control.Applicative for years. Neither has been painful. Dealing with AMP? I'm working on a collaborative research project that is stuck on 7.8 because of AMP. I agree, that seems silly, but whether or not it is silly, it is an impact I feel. One way to look at these proposals is to ask the question "Wouldn't the language be nicer if all these changes were made?" Another is to ask the question "Does the fact that these changes have not been made make your life as a Haskell programmer more difficult in any significant way?" I answer "yes" to the former and "no" to the latter. Is our stance that answering "yes" to the former question is enough to motivate braking change? Shouldn't a answer "no" to the latter question cause some hesitation? Maybe there are a lot of people who answer "yes" to both questions. I would like to know! But does having return in the Monad class really cause anyone anything other than existential pain? Cheers, Geoff [1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html [2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses

On 10/22/2015 11:02 AM, Matthias Hörmann wrote:

I would say that the need to import Control.Applicative in virtually every module manually definitely caused some pain before AMP.

In this particular case, there is a trade off between breaking code on the one hand and having to write some import statements on the other. I find writing some extra imports less painful than breaking (other people's and my) code, but the other position is defensible as well. I sense that I am in the minority, at least on the libraries list.

I would also argue that a non-negligible amount of effort goes into teaching the warts, the reasons for the warts and how to work around them.

Which wart(s) in particular? All of them? Does having return (and (>>)) in Monad make teaching more difficult? I teach Haskell beginners, and I found that AMP made explaining monads slightly more difficult because it served as a source of confusion for my students. On the other hand, the warts provide a teachable moment once students understand all this stuff :)

...

Dealing with AMP? I'm working on a collaborative research project that is stuck on 7.8 because of AMP. I am curious what exactly about AMP causes your research project to be "stuck" on GHC 7.8 considering we have had multiple people mention how little effort it took to update even large codebases. I think it would be useful information to have to plan future changes in a way that might avoid your issues.

I was hoping that mentioning this wouldn't distract from the three main (numbered) questions I posed below. Alas. If I were working alone, AMP wouldn't be a huge deal. I could fix the code for 7.10 compatibility, but then unless everyone switches to 7.10, changes to the codebase made by someone using 7.8, e.g., defining a new Monad instance, could break things on 7.10 again. It's easier to stick with 7.8. Any time spent dealing with compatibility issues is time not spent writing actual code. I outlined one possible path to avoid this kind of issue: spend more time thinking about ways to maintain compatibility. We had proposals for doing this with AMP. Cheers, Geoff

On Thu, Oct 22, 2015 at 3:29 PM, Geoffrey Mainland wrote:

...

...

On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins mailto:greg@gregorycollins.net> wrote:

On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland mailto:mainland@apeiron.net> wrote:

My original email stated my underlying concern: we are losing valuable members of the community not because of the technical decisions that are being made, but because of the process by which they are being made.

[If] you're doing research you're on the treadmill, almost by definition, and you're delighted that we're finally making some rapid progress on fixing up some of the longstanding warts.

If you're a practitioner, you are interested in using Haskell for, y'know, writing programs. You're probably in one of two camps: you're in "green field" mode writing a lot of new code (early stage startups, prototype work, etc), or you're maintaining/extending programs you've already written that are out "in the field" for you doing useful work. Laura Wingerd calls this the "annealing temperature" of software, and I think this is a nice metaphor to describe it. How tolerant you are of ecosystem churn depends on what your temperature is: and I think it should be obvious to everyone that Haskell having "success" for programming work would mean that lots of useful and correct programs get written, so everyone who is in the former camp will cool over time to join the latter.

I've made the point before and I don't really want to belabor it: our de facto collective posture towards breaking stuff, especially in the past few years, has been extremely permissive, and this alienates people who are maintaining working programs.

Even among people who purported to be teaching Haskell or using Haskell today in industry the margin of preference for the concrete FTP proposal was ~79%. This was considerably higher than I expected in two senses. One: there were a lot more people who claimed to be in one of those two roles than I expected by far, and two: their appetite for change was higher than I expected. I initially expected to see a stronger "academic vs. industry" split in the poll, but the groups were only distinguishable by a few percentage point delta, so while I expected roughly the end percentage of the poll, based on the year prior I'd spent running around the planet to user group meetings and the like, I expected it mostly because I expected more hobbyists and less support among industrialists.

I'm actually firmly of the belief that the existing committee doesn't really have process issues, and in fact, that often it's been pretty careful to minimize the impact of the changes it wants to make. As others have pointed out, lots of the churn actually comes from platform libraries, which are out of the purview of this group.

Historically we've had a bit of a split personality on this front. Nothing that touches the Prelude had changed in 17 years. On the other hand the platform libraries had maintained a pretty heavy rolling wave of breakage the entire time I've been around in the community. On a more experimental feature front, I've lost count of the number of different things we've done to Typeable or template-haskell.

All I'm saying is that if we want to appeal to or cater to working software engineers, we have to be a lot less cavalier about causing more work for them, and we need to prize stability of the core infrastructure more highly. That'd be a broader cultural change, and that goes beyond process: it's policy.

The way things are shaping up, we've had 17 years of rock solid stability, 1 release that incorporated changes that were designed to minimize impact, to the point that the majority of the objections against them are of the form where people would prefer that we broke _more_ code, to get a more sensible state. Going forward, it looks like the next 2 GHC releases will have basically nothing affecting the Prelude, and there will be another punctuation in the equilibrium around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That gives 2 years worth of advance notice of pending changes, and a pretty strong guarantee from the committee that you should be able to maintain code with a 3 release window without running afoul of warnings or needing CPP.

So, out of curiosity, what additional stability policy is it that you seek? Thanks to you and Dan [1], I now have a greater understanding and appreciation for where the committee has been coming from. My new understanding is that the changes that were formalized in AMP, FTP, and MRP were the basis for the committee's creation. It also seems that

On 10/22/2015 02:40 AM, Edward Kmett wrote: there are more changes in the pipeline that have not yet been made into proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of "stability" is signaling change as far ahead as possible. The committee has put a lot of effort into this, which I appreciate! However, as each of these proposal has come down the pipeline, I never realized that they were part of a larger master plan.

1) What is the master plan, and where is it documented, even if this document is not up to the standard of a proposal? What is the final target, and when might we expect it to be reached? What is in the pipeline after MRP?

Relatedly, guidance on how to write code now so that it will be compatible with future changes helps mitigate the stability issue.

2) How can I write code that makes use of the Prelude so that it will work with every new GHC release over the next 3 years? 5 years? For example, how can I write a Monad instance now, knowing the changes that are coming, so that the instance will work with every new GHC release for the next 3 years? 5 years? If the answer is "you can't," then when might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to say I don't know the answer!

Finally, if none of these changes broke Prelude backwards compatibility, far fewer people would be complaining :) Of course, we can't always make progress without breaking things, but a more deliberative process might offer an opportunity to make progress while still preserving backwards compatibility. Take AMP for example. There were at least two [3] [4] proposals for preserving backwards compatibility. Investigating them would have taken time and delayed AMP, yes, but why the rush?

3) Can we have a process that allows more deliberation over, and wider publicity for, changes that break backwards compatibility? The goal of such a process would not be to prevent change, but to allow more time to find possible solution to the issue of backwards compatibility.

My proposal for a low-traffic mailing list where all proposals were announced was meant to provide wider publicity.

Personally, I think these proposals do indeed fix a lot of warts in the language. As a researcher who uses actively uses Haskell every day, these warts have had approximately zero impact on me for the past (almost) decade, and I would be perfectly content if they were never fixed. The only pain I can recall enduring is having to occasionally write an orphan Applicative instance. I have been importing Prelude hiding mapM for years. I have been importing Control.Applicative for years. Neither has been painful. Dealing with AMP? I'm working on a collaborative research project that is stuck on 7.8 because of AMP. I agree, that seems silly, but whether or not it is silly, it is an impact I feel.

One way to look at these proposals is to ask the question "Wouldn't the language be nicer if all these changes were made?" Another is to ask the question "Does the fact that these changes have not been made make your life as a Haskell programmer more difficult in any significant way?" I answer "yes" to the former and "no" to the latter. Is our stance that answering "yes" to the former question is enough to motivate braking change? Shouldn't a answer "no" to the latter question cause some hesitation?

Maybe there are a lot of people who answer "yes" to both questions. I would like to know! But does having return in the Monad class really cause anyone anything other than existential pain?

Cheers, Geoff

[1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html [2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses

I outlined one possible path to avoid this kind of issue: spend more time thinking about ways to maintain compatibility. We had proposals for doing this with AMP.

And on the other hand we also had a concrete proposal that didn't require language changes that was ridiculously popular. People had been talking about Applicative as a superclass of Monad for a decade before we finally acted upon the AMP. People had been talking about superclass defaulting for a decade. When do you cut off discussion and ship the proposal that has overwhelming support? If there is no process that enables this you can stall the process indefinitely by raising objections of this form. Such a situation is not without costs all its own.

I agree. It was certainly within the power of the committee to start a clock and say something like "if we don't have a patch to GHC that provides backwards compatibility for AMP within 1 year, we will push out AMP as-is." Had I understand the implications of AMP at the time, or even been aware that AMP was happening (I was actually actively working on the GHC code base during that period), that certainly would have been motivation for me to do something about it! *That* would be how one could cut off discussion and ship a proposal. I am not against changing the Prelude! But it sure would be nice if -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a Haskell 2010 Prelude, both of which could be used with external packages that themselves used the more modern Prelude. Maybe that's impossible. Setting a firm deadline to finding a solution to the compatibility issue would have been a way to compromise. Ideally, changing the Prelude wouldn't require breaking code written to use an older version of the Prelude. Yes, attaining that goal would require more work. Evolving the Prelude and maintaining compatibility are not necessarily mutually exclusive options. Cheers, Geoff

On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland wrote:

...

I outlined one possible path to avoid this kind of issue: spend more time thinking about ways to maintain compatibility. We had proposals for doing this with AMP.

And on the other hand we also had a concrete proposal that didn't require language changes that was ridiculously popular. People had been talking about Applicative as a superclass of Monad for a decade before we finally acted upon the AMP. People had been talking about superclass defaulting for a decade. When do you cut off discussion and ship the proposal that has overwhelming support? If there is no process that enables this you can stall the process indefinitely by raising objections of this form. Such a situation is not without costs all its own.

I agree. It was certainly within the power of the committee to start a clock and say something like "if we don't have a patch to GHC that provides backwards compatibility for AMP within 1 year, we will push out AMP as-is." Had I understand the implications of AMP at the time, or even been aware that AMP was happening (I was actually actively working on the GHC code base during that period), that certainly would have been motivation for me to do something about it! *That* would be how one could cut off discussion and ship a proposal.

I freely admit that there is room for improvement in the process. We're all learning here. The current Semigroup-Monoid proposal more or less fits the bill you are looking for here. We have a roadmap today that migrates an existing package with several years worth of back support into base more or less unmodified, and then in 3 releases starts requiring instances. You can think of that 3 release clock as precisely what you are looking for here. If we get an implementation of superclass defaulting or some other mechanism that can mitigate the extra couple of lines of code that this proposal will tax users with, within that timeline, we'd gladly incorporate it into the proposal.

I am not against changing the Prelude! But it sure would be nice if -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a Haskell 2010 Prelude, both of which could be used with external packages that themselves used the more modern Prelude.

It would definitely be a preferable state of affairs. Unfortunately, at least with the tools available to us today, such a plan is incompatible with any plan that introduces a new superclass. It also cuts off plans that ever factors an existing class into two, such as the MonadFail proposals. We simply do not at this time have the technical capabilities that would support such a system. If they showed up in GHC we can adapt plans to fit.

Maybe that's impossible. Setting a firm deadline to finding a solution to the compatibility issue would have been a way to compromise. Ideally, changing the Prelude wouldn't require breaking code written to use an older version of the Prelude. Yes, attaining that goal would require more work.

We looked around for a year for a roadmap that would get us there. None presented itself. In the end we wound up shedding the core libraries status of the haskell98 and haskell2010 packages as the 3-4 different ways in which one could write a Haskell2010 package all have different trade-offs and can be maintained in user-land. Examples: * A hardline version of haskell2010 with a Monad and Num that fully complies with the report, but which doesn't work with Monad and Num instances supplied by other libraries. This needs RebindableSyntax, so it doesn't quite work right. With compiler support for rebinding syntax to a particular library instead of to whatever is in scope, such a thing might be suitable for teaching a Haskell class. * A pragmatic haskell2010 where the Monad has an Applicative superclass and Num has the current semantic. This works with everything but doesn't faithfully follow the report. * A middle-ground package that tries to use a superclass defaulting mechanism that we don't have to supply missing Applicative superclasses might resolve the Applicative-Monad issue in theory, but does nothing for report compliance of our existing Num. Each one of these solutions has flaws. Two of them require innovations in the compiler that we don't have.

Evolving the Prelude and maintaining compatibility are not necessarily mutually exclusive options.

Agreed, but as you can see above, maintaining compatibility isn't necessarily always a viable option either. -Edward

On Thu, Oct 22, 2015 at 1:41 PM, Geoffrey Mainland wrote:

On 10/22/2015 01:29 PM, Edward Kmett wrote:

...

On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland mailto:mainland@apeiron.net> wrote:

I am not against changing the Prelude! But it sure would be nice if -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a Haskell 2010 Prelude, both of which could be used with external packages that themselves used the more modern Prelude.

It would definitely be a preferable state of affairs. Unfortunately, at least with the tools available to us today, such a plan is incompatible with any plan that introduces a new superclass. It also cuts off plans that ever factors an existing class into two, such as the MonadFail proposals. We simply do not at this time have the technical capabilities that would support such a system. If they showed up in GHC we can adapt plans to fit.

Great!

Could we work to characterize what technical capabilities we would need to support full backwards Prelude compatibility?

Here is my rough understanding of what we would need:

1) Some method for "default superclasses." This would solve the AMP issue.

2) A method for factoring existing classes into two (or more) parts. This would solve the MonadFail problem.

3) A method for imposing extra superclass constraints on a class. This would be needed for full Num compatibility. Seems much less important that 1 and 2.

The most thought has gone into 1.

Are these three technical capabilities *all* that we would need? Perhaps we also need a way to tie the current language (-XHaskell98, -XHaskell2010) to a particular implementation of the Prelude.

I don't have a concrete plan here. I'm not even sure one can be achieved that works. I'd say that the burden of figuring out such a thing falls on the party that can create a plan, pitch it to the community and potentially implement it. If I enumerate a set of conditions here I'm basically implying that I'd agree to any plan that incorporated them. I'm just not prepared to make that commitment sight-unseen to something with unknown warts and implications. I can, however, say that it is plausible that what you have enumerated above could potentially address the outstanding issues, but I don't know how good of a compromise the result would be. -Edward

| > Are these three technical capabilities *all* that we would need? | > Perhaps | > we also need a way to tie the current language (-XHaskell98, | > -XHaskell2010) to a particular implementation of the Prelude. | > | > | > I don't have a concrete plan here. I'm not even sure one can be | > achieved that works. I'd say that the burden of figuring out such a | > thing falls on the party that can create a plan, pitch it to the | > community and potentially implement it. In fact there is more than one concrete plan: https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses All are complex, only partially designed, entirely unimplemented (and the implementation will be non-trivial), and lacking an active champion. The one I link to above is probably the leading contender, but it feels too complicated to me. Simon

On Thu, Oct 22, 2015 at 9:29 AM, Geoffrey Mainland wrote:

Thanks to you and Dan [1], I now have a greater understanding and appreciation for where the committee has been coming from. My new understanding is that the changes that were formalized in AMP, FTP, and MRP were the basis for the committee's creation. It also seems that there are more changes in the pipeline that have not yet been made into proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of "stability" is signaling change as far ahead as possible. The committee has put a lot of effort into this, which I appreciate! However, as each of these proposal has come down the pipeline, I never realized that they were part of a larger master plan.

The "master plan" where (>>) is concerned is that it'd be nice to get Traversable down to a minimal state and to eliminate unnecessary distinctions in the Prelude between things like mapM and traverse. Right now they have different type constraints, but this is entirely a historical artifact. But it causes problems, we have a situation where folks have commonly optimized (>>) but left (*>) unfixed. This yields different performance for mapM_ and traverse_. A consequence of the AMP is that the neither one of those could be defined in terms of the other (*>) has a default definition in terms of (<*>). (>>) has a default definition in terms of (>>=). With two places where optimizations can happen and two different definitions for operations that are logically required to be the same thing we can and do see rather radically different performance between these two things. This proposal is something that was put out as a sort of addendum to the Monad of No Return proposal for discussion, but unlike MRP has no particular impact on a sacred cow like return. We have yet to put together a timeline that incorporates the (>>) changes from MRP. 1) What is the master plan, and where is it documented, even if this

document is not up to the standard of a proposal? What is the final target, and when might we expect it to be reached? What is in the pipeline after MRP?

Relatedly, guidance on how to write code now so that it will be compatible with future changes helps mitigate the stability issue.

The current plans more or less stop with finishing the MonadFail proposal, getting Semigroup in as a superclass of Monoid, and incorporating some additional members into Floating. The working document for the timeline going forward is available here: https://ghc.haskell.org/trac/ghc/wiki/Status/BaseLibrary

2) How can I write code that makes use of the Prelude so that it will work with every new GHC release over the next 3 years? 5 years? For example, how can I write a Monad instance now, knowing the changes that are coming, so that the instance will work with every new GHC release for the next 3 years? 5 years? If the answer is "you can't," then when might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to say I don't know the answer!

We have a backwards facing "3 release policy" that says it should always be possible to write code that works backwards for 3 releases. This means that changes like moving fail out of Monad will take 5 years. However, maintaining both that and a _forward facing_ 3 release policy would mean that any change that introduced a superclass would take something like 9 years of intermediate states that make no sense to complete. *9 years to move one method.* Now looking forward. You can write code today with 7.10 that will work without warnings until 8.2. That happens to be 3 releases. In 8.4 you'll start to get warnings about Semigroup and MonadFail changes, but looking at it as 3 releases going forward in 8.0 you can just write the instances and your code would be warning free forward for 3 releases. In 8.6 those changes go into effect, but you will have been able to make the code changes that you need to accomodate 8.6 since 8.0. The current roadmap happens to give you a 3 year sliding window. Finally, if none of these changes broke Prelude backwards compatibility,

far fewer people would be complaining :)

If none of our changes were ever able to break Prelude backwards compatibility the same people who have been complaining about the utter lack of progress for the previous 17 years and that nearly exploded the community 2 years ago would be complaining, and based on polling and discusssions that is actually a much larger group. The AMP passed nearly unanimously.

Of course, we can't always make progress without breaking things, but a more deliberative process might offer an opportunity to make progress while still preserving backwards compatibility. Take AMP for example. There were at least two [3] [4] proposals for preserving backwards compatibility. Investigating them would have taken time and delayed AMP, yes, but why the rush?

We've been talking about various superclass defaulting proposals for the better part of a decade and no progress has been made. The rush was that we'd been letting them block every previous discussion, and that the concrete plan with an actual implementation that was on hand was a very popular proposal even without that mitigation strategy. 3) Can we have a process that allows more deliberation over, and wider

publicity for, changes that break backwards compatibility? The goal of such a process would not be to prevent change, but to allow more time to find possible solution to the issue of backwards compatibility.

My proposal for a low-traffic mailing list where all proposals were announced was meant to provide wider publicity.

I don't think anybody has an objection to wider visibility of proposals that affect things mentioned in the Haskell Report.

Personally, I think these proposals do indeed fix a lot of warts in the language. As a researcher who uses actively uses Haskell every day, these warts have had approximately zero impact on me for the past (almost) decade, and I would be perfectly content if they were never fixed. The only pain I can recall enduring is having to occasionally write an orphan Applicative instance. I have been importing Prelude hiding mapM for years. I have been importing Control.Applicative for years. Neither has been painful.

And yet the vast preponderance of public opinion lies in the other camp. The "change nothing" policy had an iron grip on the state of affairs for 17 years and there were serious cracks starting to form from the appearance that nothing could ever be fixed if the Prelude was affected in any way. The only thing that broke with that was when Ian Lynagh unilaterally removed Eq and Show as superclasses of Num. That was more or less the first glimmer that the world wouldn't end if deliberated changes were made to the Prelude. Dealing with AMP? I'm working on a

collaborative research project that is stuck on 7.8 because of AMP. I agree, that seems silly, but whether or not it is silly, it is an impact I feel.

What changes did you face beyond writing instance Functor Foo where fmap = liftM instance Applicative Foo where pure = return (<*>) = ap that is AMP related? Maybe there are a lot of people who answer "yes" to both questions. I

would like to know! But does having return in the Monad class really cause anyone anything other than existential pain?

The MRP is by far the most marginal proposal on the table. This is why it remains *just a proposal* and not part of the roadmap. That said, moving return to a top level definition will mean that more code that is compiled will be able to infer an Applicative constraint. The other proposals that are on the roadmap on the other hand defend a lot better. The (>>) fragment of MRP fixes rampant performance regressions, however. We went to generalize the implementation of mapM_ to use (*>) internally and found performance regressions within base itself due to instances that are optimized inconsistently. This informed the design here. More code will infer with weaker Applicative constraints, Traversable can eventually be simplified, and folks like Simon Marlow who have folks internally at Facebook use mapM will just have their code "work" in Haxl. I can answer "yes" to both of your questions here. The continued existence of fail in Monad on the other hand has caused a great deal of pain in instances for things like `Either a` for years. To supply `fail`, we used to incur a needless Error a constraint. We can be more precise and remove a potential source of partiality from a lot of code. I can answer "yes" to both of your questions here. The lack of Semigroup as a superclass of Monoid has meant that the Monoid instance for Maybe adds a unit to something that already has a unit. It means that First and Last, etc. all useless tack an extra case that everyone has to handle in. It has dozens of knock-on consequences. Much code that currently only needs a semigroup falls back on a monoid because of the lack of a proper class relationship or gets duplicated. I can answer "yes" to both of your questions here. The numerics changes to Floating mean that Haskell numerics just have awful precision. Adding expm1, etc. to Floating means that people will be able to write decent numerical code without having to choose between generality (using exp from Floating that works everywhere) and accuracy. I can answer "yes" to both of your questions here. -Edward

On Thu, Oct 22, 2015 at 1:37 PM, Gregory Collins wrote:

On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett wrote:

...

All I'm saying is that if we want to appeal to or cater to working

...

software engineers, we have to be a lot less cavalier about causing more work for them, and we need to prize stability of the core infrastructure more highly. That'd be a broader cultural change, and that goes beyond process: it's policy.

The way things are shaping up, we've had 17 years of rock solid stability

I have >95% confidence that all of the C++ programs I wrote 15 years ago would build and work if I dusted them off and typed "make" today. I have Haskell programs I wrote last year that I probably couldn't say that about.

So I don't buy that, at all, at least if we're discussing the topic of the stability of the core infrastructure in general rather than changes being made to the Prelude. It's been possible to write to Haskell 98 without too much breakage, yes, but almost nobody actually does that; they write to Haskell as defined by GHC + the boot libraries + Haskell platform + Hackage, IMO with decreasing expectations of stability for each. The core set breaks a lot.

I definitely agree here. We have a lot of libraries in the Haskell Platform that have fairly liberal change policies. On the other hand, we have a policy of "maintainer decides" around issues. This yields a fairly decentralized change management process, with different maintainers who have different views. The Platform gives us a central pool of packages that are generally the "best of breed" in their respective spaces, but gives us few stability guarantees. Heck, every release I wind up having to change whatever code I have that uses template-haskell or Typeable. On the other hand, it isn't clear with a larger "core" platform with harder stability guarantees that we have a volunteer force that can and would sign up for the long slog of maintenance without that level of autonomy.

We definitely shouldn't adopt a posture to breaking changes as conservative as the C++ committee's, and literally nobody in the Haskell community is arguing against breaking changes in general, but as I've pointed out, most of these breakages could have been avoided with more careful engineering, and indeed, on many occasions the argument has been made and it's fallen on deaf ears.

I would argue that there are individual maintainers that give lie to that statement. In many ways Johan himself has served as a counter-example there. The libraries he has maintained have acted as a form of bedrock with long maintenance windows. On the other hand, the burden of maintaining that stability seems to have ultimately burned him out. They can speak for themselves but I think for Mark and Johan, this is a

"straw that broke the camel's back" issue rather than anything to do with the merits of removing return from Monad. I think the blowback just happens to be so much stronger on MRP because the breaking change is so close to the core of the language, and the benefits are so nebulous. fixing an aesthetic problem has almost zero practical value

I personally don't care about the return side of the equation. Herbert's MRP proposal was an attempt by him to finish out the changes started by AMP so that a future Haskell Report can read cleanly. Past reports have been remarkably free of historical baggage. I'd personally readily sacrifice "progress" there in the interest of harmony. Herbert as haskell-prime chair possibly feels differently.

and ">> could be slightly more efficient for some monads" is pretty weak sauce.

The issue right now around (>>) is that it has knock-on effects that run pretty far and wide. "Weak sauce" or not, it means through second order consequences that we can't move the useless mapM and sequence to the top level from their current status as memberrs of Traversable and that users have to care about which of two provably equivalent things that they are using, at all times. It means that code that calls mapM will be less efficient and that mapM_ behaves in a manner with rather radically different space and time behavior than mapM today and not in a consistently good way. -Edward

On 22/10/2015 01:42, Gregory Collins wrote:

All I'm saying is that if we want to appeal to or cater to working software engineers, we have to be a lot less cavalier about causing more work for them, and we need to prize stability of the core infrastructure more highly. That'd be a broader cultural change, and that goes beyond process: it's policy.

Not that I disagree that we need general stability but, I think it's quite unfair to say that working software engineers are being pushed away because of the current "instability", and actually I don't see any proof of such a thing. Working software engineers have developed methods to deal with change (or not to deal with it) for decades. To name a few with Haskell: private hackage, stackage, cabal pinning. It's also commonly available through stack nowadays. Also, having worked on multiples different Haskell teams doing commercial/professional software, compiler/libraries upgrades were never a concern of the team. It was always something that can be dealt quickly, painlessly and with a lot more certitude w.r.t the quality assurance, compared to e.g. dynamic languages where you don't have any types safety etc.. I can't help but think that you meant "opensource library maintainers" instead of "working software engineers", which is somewhat a very different beast. -- Vincent

For proposal 3, I don't see what difference it makes whether a refreshed Haskell committee or a new libraries committee makes decisions that affect backwards compatibility. A name doesn't ensure good decision making. The only difference I can see is that the Haskell committee might only publish final decisions every couple years. But the Haskell report also isn't designed to describe migration plans between feature revisions; unless the plan is to start incorporating library deprecation and whatnot into the report (which would be odd to me). But that would just be doing the same thing slower, so it'd be little different than making library changes over 6 to 9 GHC versions instead of 3. For proposal 2, I don't know how effective it will be in practice. I believe it is already the job of a proposal submitter to summarize the arguments made about it, according to the library proposal guidelines. We could post those summaries to another list. But unless more people promise they will be diligent about reading that list, I'm not sure that one factor in these dust ups (surprise) will actually be any different. Also, if amount of discussion is at issue, I'm not sure I agree. For AMP, I was waiting a decade, more or less. I thought we should do it, other people thought we shouldn't because it would break things. I don't know what more there was to discuss, except there was more stuff to break the longer we waited. As for FTP, some aspects only became known as the proposal was implemented, and I don't know that they would have been realized regardless of how long the proposal were discussed. And then we still had a month or so of discussion after the implementation was finalized, on the cusp of GHC 7.10 being released. So how much more _was_ needed, that people are now discussing it again? If it's just about documenting more things, there's certainly no harm in that. For 1, I don't have a very strong opinion. If pressed, I would probably express some similar sentiments to Henrik. I certainly don't think Haskell would be nearly as good as it is if it were a simple majority vote by all users (and I probably wouldn't use it if that's how things were decided). Would a community vote for libraries committee be better than appointment by people who previously held the power (but have more to do than any human can accomplish)? I don't know. I should say, though, that things are not now run by simple majority vote. What we conducted a year ago was a survey, where people submitted their thoughts. I didn't get to read them, because they were private, and it wasn't my decision to make. But it was not just +80 -20. With regard to your last paragraph, unless I've missed something (and I confess that I haven't read every comment in these threads), the recent resignations didn't express disagreement with the decision making process. They expressed disagreement with the (technical) decisions (and their effects). I don't see how a different process could have solved that unless it is expected that it would have made different decisions. -- Dan On Wed, Oct 21, 2015 at 6:18 PM, Geoffrey Mainland wrote:

Hi Dan,

Thank you for the historical perspective.

I was careful not to criticize the committee. Instead, I made three concrete proposals with the hope that they would help orient a conversation.

It sounds like you are not for proposal 3. How about the other two?

My original email stated my underlying concern: we are losing valuable members of the community not because of the technical decisions that are being made, but because of the process by which they are being made. That concern is what drove my proposals. It is perfectly valid to think that that loss was the inevitable price of progress, but that is not my view.

Cheers, Geoff

On 10/21/15 5:22 PM, Dan Doel wrote:

...

Hello,

I'm Dan Doel. I'm on the core libraries committee (though I'm speaking only for myself). As I recall, one of the reasons I got tapped for it was due to my having some historical knowledge about Haskell; not because I was there, but because I've gone back and looked at some old reports and whatnot (and sometimes think they're better than what we have now).

But, I was around (of course) when the core libraries committee started up, so perhaps I can play the role of historian for this as well.

The reason the committee exists is because a couple years ago, people brought up the ideas that were finally realized in the Applicative-Monad proposal and the Foldable-Traversable proposal. A lot of people weighed in saying they thought they were a good idea, and significantly fewer people weighed in saying they thought that it shouldn't happen for various reasons---roughly the same things that people are still bringing up about these proposals.

This wasn't the first time that happened, either. I think it was widely agreed among most users that Functor should be a superclass of Monad since I started learning Haskell around 10 years ago. And once Applicative was introduced, it was agreed that that should go in the middle of the two. But it appeared that it would never happen, despite a significant majority thinking it should, because no one wanted to do anything without pretty much unanimous consent.

So, one question that got raised is: why should this majority of people even use Haskell/GHC anymore? Why shouldn't they start using some other language that will let them change 15-year-old mistakes, or adapt to ideas that weren't even available at that time (but are still fairly old and established, all things considered). And the answer was that there should be some body empowered to decide to move forward with these ideas, even if there is some dissent. And frankly, it wasn't going to be the prime committee, because it hadn't shown any activity in something like 3 years at the time, and even when it was active, it didn't make anywhere near the sort of changes that were being discussed.

And the kicker to me is, many things that people are complaining about again (e.g. the FTP) were the very things that the committee was established to execute. I don't think we had a formal vote on that proposal, because we didn't need to. Our existence was in part to execute that proposal (and AMP). And then a year ago, when it was finally time to release the changes, there was another ruckus. And we still didn't have a CLC vote on the matter. What we did was conduct a community poll, and then SPJ reviewed the submissions. But I don't mean to pass the buck to him, because I'm pretty sure he was worried that we were crazy, and overstepping our bounds. Just, the results of the survey were sufficient for him to not overrule us.

So my point is this: there seems to be some sentiment that the core libraries committee is unsound, and making bad decisions. But the complaints are mostly not even about actual decisions we made (aside from maybe Lennart Augustsson's, where he is unhappy with details of the FTP that you can blame on us, but were designed to break the least code, instead of being the most elegant; if we had pleased him more, we would have pleased others less). They are about the reasons for founding the committee in the first place. You can blame us, if you like, because I think it's certain that we would have approved them if we had formally voted. We just didn't even need to do so.

Forgive me if I'm wrong, but suggestions that these decisions should have been deferred to a Haskell Prime committee mean, to me, that the hope is that they would have been rejected. That the Haskell Prime committee should have just vetoed these proposals that something like 80% or more of practicing Haskell users (as far as we can tell) wanted for years before they finally happened. That the Haskell Prime committee should be responsible for enforcing the very status quo that led to the CLC in the first place, where proposals with broad support but minority dissent never pass for various core modules.

If this is the case, then one could simply repose the earlier question: why should most of these people stick around to obey by the Haskell Prime committee's pronouncements, instead of getting to work on a language that incorporates their input?

And if it isn't, then I don't ultimately understand what the complaints are. We try to accomplish the (large) changes in a manner that allows transition via refactoring over multiple versions (and as I mentioned earlier, some complaints are that we compromised _too much_ for this). And in light of the more recent complaints, it's even been decided that our time frames should be longer. Rolling up changes into a report just seems like it makes transitions less smooth. Unless the idea is to make GHC capable of switching out entire base library sets; but someone has to implement that, and once you have it, it makes the report specifications _less_ essential.

Anyhow, that's my history lesson. Take it as you (all) will.

Cheers, -- Dan

On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland wrote:

...

On 10/21/2015 07:30 AM, Simon Peyton Jones wrote:

...

Friends

I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future. Geoff's message had some good ideas, especially this bit:

| Proposal 2: After a suitable period of discussion on the libraries list, the | Core Libraries Committee will summarize the arguments for and against a | proposal and post it, along with a (justified) preliminary decision, to a | low-traffic, announce-only email list. After another suitable period of | discussion, they will issue a final decision. What is a suitable period of | time? Perhaps that depends on the properties of the proposal, such as | whether it breaks backwards compatibility.

Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing. I believe that the Core Libraries committee is thinking actively about this.

| Personally, I think AMP was the right thing to do, but I don't think FTP was | the right thing.

These make good examples to motivate future changes to our process. But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above. We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction. In a big community, even a broad consultation may yield a result that some think is ill-advised. That's part of the joyful burden of being a big community.

Let's look forward, not back. I think we can do better in future than we have done in the past. I don't think we can hope for unanimity, but I think we can reasonably seek

* transparency; * clarity about what decisions are on the table; * broad consultation about decisions that affect a broad constituency; and * a decent opportunity to debate them without having to be involved in massive email threads. Let's try do to that.

Simon

PS: For what it's worth I'm less keen on Geoff's other proposal:

| Proposal 3: A decision regarding any proposal that significantly affects | backwards compatibility is within the purview of the Haskell Prime | Committee, not the Core Libraries Committee.

*Precisely* the same issues will arise whether it's CLC or HPC. And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it. For the record, I am also not sure Proposal 3 is a good idea :)

However, I do think we could clarify what the respective responsibilities of the core libraries committee and Haskell Prime committees are.

One possible choice is that the core libraries committee is responsible for changes to the core libraries that do not affect libraries in the report. It is meant to be nimble, able to quickly deal with the large volume of library changes that do not impact backwards compatibility.

In this scenario, the Haskell Prime committee, using a longer deliberative process, would consider the more impactful library changes and batch them up into new reports.

You are absolutely correct that moving the question to the Haskell Prime committee risks pushing the issue around. The idea behind the separation outlined above is to reduce the treadmill; the two bodies use different processes, with different time frames, to arrive at decisions. Some library decisions may deserve a longer deliberative process.

Cheers, Geoff _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

| For the record, I am also not sure Proposal 3 is a good idea :) | | However, I do think we could clarify what the respective | responsibilities of the core libraries committee and Haskell Prime | committees are. My instinct is this: Haskell Prime: language Core Libraries Committee: libraries That seems simple. If we try to move the largest and most challenging library design tasks from CLC to HP, I fear that we will overload the latter and devalue the former. | You are absolutely correct that moving the question to the Haskell Prime | committee risks pushing the issue around. The idea behind the separation | outlined above is to reduce the treadmill; the two bodies use different | processes, with different time frames, to arrive at decisions. Some | library decisions may deserve a longer deliberative process. I do agree that some library changes are far-reaching, and need a more deliberative process. I think the CLC is in the process of developing such a process. Moreover, I trust them to be able to tell the difference between low-impact and high-impact changes. That said, as HP moves towards a new language Report, it would be good if CLC similarly moved towards a new libraries Report, so that there was a single unified document, just as we have had to date. Simon

Henrik Nilsson-2 wrote

Jeremy wrote:

...

There seems to be a fair amount of friction between those who want to introduce new features or fix significant historical warts in the base libraries - even if this requires breaking changes - and those who insist on no significant breaking changes in new releases, regardless of the reason or how much warning was given.

With respect, and without commenting on the merits of the proposal that is then outlined (Long-Term Support Haskell), I don't think this is an accurate description of the two main positions in the debate at all.

Most of those who have argued against MRP, for example, have made it very clear that they are not at all against any breaking change. But they oppose breaking changes to Haskell itself, including central libraries, as defined by the Haskell report, unless the benefits are very compelling indeed.

With equal respect, I stopped following the MRP thread when its length exceeded my interest, so my comments may not be applicable here :-) The LTS solution should work as long as all (or at least a big enough majority) agree that the benefits of a change are desirable, but disagree as to the cost of breaking change. It allows the "nice idea but don't keep breaking my code" people to co-exist with the "nice idea let's do it" people. -- View this message in context: http://haskell.1045720.n5.nabble.com/Monad-of-no-return-Proposal-MRP-Moving-... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

Kim-Ee Yeoh wrote

But as Henrik and Lennart have alluded to, what we have currently is friction between "half-baked idea, I'll fight against it" and "nice idea, this is the way to progress."

LTS, seen in this light, is a discussion-postponing move.

What's needed is a "let's agree to disagree and have a long, deep discussion to understand one another", not "let's agree to disagree. Here's software for you. And here's software for me. Bye-bye."

Indeed, LTS is only relevant after a proposal has been agreed upon in principle, and the only issue is whether it's worth a breaking change. AMP may be a good example of where this would help. -- View this message in context: http://haskell.1045720.n5.nabble.com/Monad-of-no-return-Proposal-MRP-Moving-... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

My rationale for proposing LTS as a solution is that this is the model which enterprise users have already adopted this for other technologies, despite the big jump between releases. I'm not theorising about a proposition which may work for users seeking long-term stability, I'm describing the solution which they're already using and happy with for other technologies. -- View this message in context: http://haskell.1045720.n5.nabble.com/Monad-of-no-return-Proposal-MRP-Moving-... Sent from the Haskell - Libraries mailing list archive at Nabble.com.

Hello, On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: [...]

In effect, only those who actively follow the libraries list have had a voice in these decisions. Maybe that is what the community wants. I hope not. How then can people like me (and Henrik and Graham) have a say without committing to actively following the libraries list?

We have a method to solve this: elected representatives. Right now the Core Libraries Committee elects its own members; perhaps it is time for that to change.

[...]

Proposal 1: Move to community election of the members of the Core Libraries Committee. Yes, I know this would have its own issues.

How exactly do public elections of representatives address the problem that some people feel left out? Have you considered nominating yourself or somebody else you have confidence in for the core libraries committee? You'd still have to find somebody to represent your interests, regardless of whether the committee is self-elected or direct-elected. Here's some food for thought regarding language design by voting or its indirect form via a directly elected language committee: Back in February there was a large-scale survey which resulted (see [2] for more details) in a rather unequivocal 4:1 majority *for* going through with the otherwise controversial FTP implementation. If the community elections would result in a similar spirit, you'd could easily end up with a similarly 4:1 pro-change biased committee. Would you consider that a well balanced committee formation?

Proposal 2: After a suitable period of discussion on the libraries list, the Core Libraries Committee will summarize the arguments for and against a proposal and post it, along with a (justified) preliminary decision, to a low-traffic, announce-only email list. After another suitable period of discussion, they will issue a final decision. What is a suitable period of time? Perhaps that depends on the properties of the proposal, such as whether it breaks backwards compatibility.

That generally sounds like a good compromise, if this actually helps reaching the otherwise unreachable parts of the community and have their voices heard.

Proposal 3: A decision regarding any proposal that significantly affects backwards compatibility is within the purview of the Haskell Prime Committee, not the Core Libraries Committee.

I don't see how that would change much. The prior Haskell Prime Committee has been traditionally self-elected as well. So it's just the label of the committee you'd swap out. In the recent call of nominations[1] for Haskell Prime, the stated area of work for the new nominations was to take care of the *language* part, because that's what we are lacking the workforce for. Since its creation for the very purpose of watching over the core libraries, the core-libraries-committee has been almost exclusively busy with evaluating and deciding about changes to the `base` library and overseeing their implementation. Transferring this huge workload to the new Haskell Prime committee members who have already their hands full with revising the language part would IMO just achieve to reduce the effectiveness of the upcoming Haskell Prime committee, and therefore increase the risk of failure in producing an adequate new Haskell Report revision. Regards, H.V.Riedel [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html

Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > > [...]

...

...

In effect, only those who actively follow the libraries list have had a >> voice in these decisions. Maybe that is what the community wants. I hope >> not. How then can people like me (and Henrik and Graham) have a say >> without committing to actively following the

or somebody else you have confidence in for the core libraries > committee? You'd still have to find somebody to represent your > interests, regardless of whether the committee is self-elected or >

...

Proposal 2: After a suitable period of discussion on the libraries list, >> the Core Libraries Committee will summarize the arguments for and >> against a proposal and post it, along with a (justified) preliminary >> decision, to a low-traffic, announce-only email list. After another >> suitable period of discussion, they will issue a final decision. What is a suitable period of time? Perhaps that depends on the properties of

On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote: libraries list? >> >> We have a method to solve this: elected representatives. Right now the >> Core Libraries Committee elects its own members; perhaps it is time for >> that to change. > > [...] > >> Proposal 1: Move to community election of the members of the Core >> Libraries Committee. Yes, I know this would have its own issues. > > How exactly do public elections of representatives address the problem > that some people feel left out? Have you considered nominating yourself direct-elected. > > Here's some food for thought regarding language design by voting or its > indirect form via a directly elected language committee: > > Back in February there was a large-scale survey which resulted (see [2] > for more details) in a rather unequivocal 4:1 majority *for* going > through with the otherwise controversial FTP implementation. If the > community elections would result in a similar spirit, you'd could easily > end up with a similarly 4:1 pro-change biased committee. Would you > consider that a well balanced committee formation? Thanks, all good points. It is quite possible that direct elections would produce the exact same committee. I wouldn't see that as a negative outcome at all! At least that committee would have been put in place by direct election; I would see that as strengthening their mandate. I am very much aware of the February survey. I wonder if Proposal 2, had it been in place at the time, would have increased participation in the survey. The recent kerfuffle has caught the attention of many people who don't normally follow the libraries list. Proposal 1 is an attempt to give them a voice. Yes, they would still need to find a candidate to represent their interests. If we moved to direct elections, I would consider running. However, my preference is that Proposal 3 go through in some form, in which case my main concern would be the Haskell Prime committee, and unfortunately nominations for that committee have already closed. the >> proposal, such as whether it breaks backwards compatibility. > > That generally sounds like a good compromise, if this actually helps > reaching the otherwise unreachable parts of the community and have their

voices heard.

...

Proposal 3: A decision regarding any proposal that significantly affects >> backwards compatibility is within the purview of the Haskell Prime Committee, not the Core Libraries Committee. > > I don't see how that would change much. The prior Haskell Prime > Committee has been

My hope is that a low-volume mailing list would indeed reach a wider audience. traditionally self-elected as well. So it's just the > label of the committee you'd swap out. > > In the recent call of nominations[1] for Haskell Prime, the stated area > of work for the new nominations was to take care of the *language* part, > because that's what we are lacking the workforce for. > > Since its creation for the very purpose of watching over the core > libraries, the core-libraries-committee has been almost exclusively busy > with evaluating and deciding about changes to the `base` library and > overseeing their implementation. Transferring this huge workload to the > new Haskell Prime committee members who have already their hands full > with revising the language part would IMO just achieve to reduce the > effectiveness of the upcoming Haskell Prime committee, and therefore > increase the risk of failure in producing an adequate new Haskell Report > revision. My understanding is that much of the work of the core libraries committee does not "significantly affect backwards compatibility," at least not to the extent that MRP does. If this is the case, the bulk of their workload would not be transferred to the new Haskell Prime committee. Is my understanding incorrect? The intent of Proposal 3 was to transfer only a small fraction of the issues that come before the core libraries committee to the Haskell Prime committee. In any case, we would certainly need to clarify what "significantly affects backwards compatibility" means. Perhaps we should consider direct elections for the Haskell Prime committee as well as changing their mandate to include some subset of the changes proposed to libraries covered by the Haskell Report. My understanding of the current state of affairs is that the Haskell Prime committee is charged with producing a new report, but the core libraries committee is in charge of the library part of that report. Is that correct? Cheers, Geoff

Regards, > H.V.Riedel > > [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html

Thanks for the background, Edward. I don't mean to question the composition of the committee, only to start a discussion about how the community might handle the selection process going forward. I apologize if I was not clear about that. As I said below, if a direct vote resulted in the same committee we would have had under the current system, I would consider that a success! We may also see a larger nomination pool in the future :) Cheers, Geoff On 10/21/2015 03:54 PM, Edward Kmett wrote:

The committee was formed from a pool of suggestions supplied to SPJ that represented a fairly wide cross-section of the community.

Simon initially offered both myself and Johan Tibell the role of co-chairs. Johan ultimately declined.

In the end, putting perhaps too simple a spin on it, the initial committee was selected: Michael Snoyman for commercial interest, Mark Lentczner representing the needs of the Platform and implementation concerns, Brent Yorgey on the theory side, Doug Beardsley representing practitioners, Joachim Breitner had expressed interest in working on split base, which at the time was a much more active concern, Dan Doel represented a decent balance of theory and practice.

Since then we had two slots open up on the committee, and precisely two self-nominations to fill them, which rather simplified the selection process. Brent and Doug rotated out and Eric Mertens and Luite Stegeman rotated in.

Technically, yes, we are self-selected going forward, based on the precedent of the haskell.org http://haskell.org committee and haskell-prime committees, but you'll note this hasn't actually been a factor yet as there hasn't been any decision point reached where that has affected a membership decision.

-Edward

On Wed, Oct 21, 2015 at 8:31 AM, Geoffrey Mainland mailto:mainland@apeiron.net> wrote:

On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote: > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > > [...] > >> In effect, only those who actively follow the libraries list have had a >> voice in these decisions. Maybe that is what the community wants. I hope >> not. How then can people like me (and Henrik and Graham) have a say >> without committing to actively following the libraries list? >> >> We have a method to solve this: elected representatives. Right now the >> Core Libraries Committee elects its own members; perhaps it is time for >> that to change. > > [...] > >> Proposal 1: Move to community election of the members of the Core >> Libraries Committee. Yes, I know this would have its own issues. > > How exactly do public elections of representatives address the problem > that some people feel left out? Have you considered nominating yourself > or somebody else you have confidence in for the core libraries > committee? You'd still have to find somebody to represent your > interests, regardless of whether the committee is self-elected or > direct-elected. > > Here's some food for thought regarding language design by voting or its > indirect form via a directly elected language committee: > > Back in February there was a large-scale survey which resulted (see [2] > for more details) in a rather unequivocal 4:1 majority *for* going > through with the otherwise controversial FTP implementation. If the > community elections would result in a similar spirit, you'd could easily > end up with a similarly 4:1 pro-change biased committee. Would you > consider that a well balanced committee formation?

Thanks, all good points.

It is quite possible that direct elections would produce the exact same committee. I wouldn't see that as a negative outcome at all! At least that committee would have been put in place by direct election; I would see that as strengthening their mandate.

I am very much aware of the February survey. I wonder if Proposal 2, had it been in place at the time, would have increased participation in the survey.

The recent kerfuffle has caught the attention of many people who don't normally follow the libraries list. Proposal 1 is an attempt to give them a voice. Yes, they would still need to find a candidate to represent their interests. If we moved to direct elections, I would consider running. However, my preference is that Proposal 3 go through in some form, in which case my main concern would be the Haskell Prime committee, and unfortunately nominations for that committee have already closed.

>> Proposal 2: After a suitable period of discussion on the libraries list, >> the Core Libraries Committee will summarize the arguments for and >> against a proposal and post it, along with a (justified) preliminary >> decision, to a low-traffic, announce-only email list. After another >> suitable period of discussion, they will issue a final decision. What is >> a suitable period of time? Perhaps that depends on the properties of the >> proposal, such as whether it breaks backwards compatibility. > > That generally sounds like a good compromise, if this actually helps > reaching the otherwise unreachable parts of the community and have their > voices heard.

My hope is that a low-volume mailing list would indeed reach a wider audience.

>> Proposal 3: A decision regarding any proposal that significantly affects >> backwards compatibility is within the purview of the Haskell Prime >> Committee, not the Core Libraries Committee. > > I don't see how that would change much. The prior Haskell Prime > Committee has been traditionally self-elected as well. So it's just the > label of the committee you'd swap out. > > In the recent call of nominations[1] for Haskell Prime, the stated area > of work for the new nominations was to take care of the *language* part, > because that's what we are lacking the workforce for. > > Since its creation for the very purpose of watching over the core > libraries, the core-libraries-committee has been almost exclusively busy > with evaluating and deciding about changes to the `base` library and > overseeing their implementation. Transferring this huge workload to the > new Haskell Prime committee members who have already their hands full > with revising the language part would IMO just achieve to reduce the > effectiveness of the upcoming Haskell Prime committee, and therefore > increase the risk of failure in producing an adequate new Haskell Report > revision.

My understanding is that much of the work of the core libraries committee does not "significantly affect backwards compatibility," at least not to the extent that MRP does. If this is the case, the bulk of their workload would not be transferred to the new Haskell Prime committee. Is my understanding incorrect?

The intent of Proposal 3 was to transfer only a small fraction of the issues that come before the core libraries committee to the Haskell Prime committee. In any case, we would certainly need to clarify what "significantly affects backwards compatibility" means.

Perhaps we should consider direct elections for the Haskell Prime committee as well as changing their mandate to include some subset of the changes proposed to libraries covered by the Haskell Report. My understanding of the current state of affairs is that the Haskell Prime committee is charged with producing a new report, but the core libraries committee is in charge of the library part of that report. Is that correct?

Cheers, Geoff

> Regards, > H.V.Riedel > > [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html > [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html