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 <mark.lentczner@gmail.com> wrote:
On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <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.
This whole discussion is tilted towards the software engineering side.I think there are several different conversations going on at once in this thread. I think it’s worth keeping them separate.
<snip>
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