<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner <<a href="mailto:mark.lentczner@gmail.com">mark.lentczner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br>On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="overflow:hidden">TLDR: To complete the AMP, turn `Monad(return)` method into a<br>      top-level binding aliasing `Applicative(pure)`.<br></div></blockquote><div><br></div><div>Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't.</div><div><br></div><div>A modest proposal:</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>#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?</div><div><br></div><div>#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?<br></div></div></div>