On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner wrote:

On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel wrote:

...

TLDR: To complete the AMP, turn `Monad(return)` method into a top-level binding aliasing `Applicative(pure)`.

Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't.

A modest proposal:

We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc.

I'm just curious how much you think this would help, assuming that your solution would imply not upgrading to 8 until you're ready to. After all, you can already simply not upgrade now, and create (and distribute) fixes for bugs, security issues, cross-compatibility for 7 as you see fit. While that's a popular thing to do in lots of systems (but if we don't it. for gnus sake let's not adopt the inane parity implies stability numbering convention), it leaves two major issues unaddressed. #1, developer time. You need to get the people doing the work now to divide their efforts into the two branches.I don't know what percentage of that work is volunteer time, but I expect the answer is "most of it". If they aren't interested doing that now, what do you expect to change their mind? #2, everything else in the ecosystem. If you need updates to a library that require the branch you're not using, where does that leave you?

I think there are several different conversations going on at once in this thread. I think it’s worth keeping them separate. · Haskell Prime. The intention there is to take a set of language features that are already in wide use in GHC (i.e. have demonstrably proved valuable), work out any dark corners, formalise them, and embody the result in a new Haskell Report. That puts a useful stake in the ground, empowers alternative implementations of Haskell, gives confidence all round. I think it’d be unusual for the Haskell Prime committee to specify a new feature of the language, one that had not been field tested. · Libraries. AMP, BBP, and Monad(return) are small but fundamental changes to the core libraries. I think there was a consensus (not universal in the case of BBP) that the change was good. Yet AMP and BBP (esp) were controversial. The issues were mostly around how to make the transition; and, given that the transition is expensive, whether the cost/benefit tradeoff justifies the change. The question of moving ‘return’ out of Monad is in this category. The Core Libraries Committee was formed explicitly to handle this stuff. So my prior assumption was that the CLC would handle the Monad(return) question, not Haskell Prime. Mark’s suggestion of a “stable” GHC 7.10 and a new GHC 8.0 is a reasonable one. But I for one would find it hard to promise to back-port every bug fix, especially as the two code bases diverge (which they will). Here is another idea. GHC knows very little about Monad. It would take work, but it probably wouldn’t be impossible to make the same GHC work with two different ‘base’ libraries, each with a different definitions of the Monad class. That would not solve the problem: you still could not use one library that used old Monad with another library that used new Monad. But at least it’d decouple it from which version of GHC you were using. I stress: it would take some work to make this go, and I’d prefer not to do this. Returning to ‘return’, my instinct is that when these pervasive breaking library changes come up, we should batch them into larger clumps. The “treadmill” complaint is real: small change A made me re-release my library; then small change B came along; and so on. Perhaps if we saved them up this would be less of an issue, for two reasons. First, the work happens once rather than many times. Second, the benefits of the change is the sum of the benefits of the little component changes, and so is more attractive to library authors and library clients. That line of thinking would suggest that the Core Libraries Committee might want to maintain a list of well-worked out agreed changes that are being “saved up” for execution at some later date. Simon From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Mike Meyer Sent: 07 October 2015 00:24 To: Mark Lentczner; Johan Tibell Cc: Haskell Libraries; haskell cafe; haskell-prime@haskell.org List Subject: Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner mailto:mark.lentczner@gmail.com> wrote: On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel mailto:hvr@gnu.org> wrote: TLDR: To complete the AMP, turn `Monad(return)` method into a top-level binding aliasing `Applicative(pure)`. Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't. A modest proposal: We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc. I'm just curious how much you think this would help, assuming that your solution would imply not upgrading to 8 until you're ready to. After all, you can already simply not upgrade now, and create (and distribute) fixes for bugs, security issues, cross-compatibility for 7 as you see fit. While that's a popular thing to do in lots of systems (but if we don't it. for gnus sake let's not adopt the inane parity implies stability numbering convention), it leaves two major issues unaddressed. #1, developer time. You need to get the people doing the work now to divide their efforts into the two branches.I don't know what percentage of that work is volunteer time, but I expect the answer is "most of it". If they aren't interested doing that now, what do you expect to change their mind? #2, everything else in the ecosystem. If you need updates to a library that require the branch you're not using, where does that leave you?