<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 22, 2015 at 1:37 PM, Gregory Collins <span dir="ltr"><<a href="mailto:greg@gregorycollins.net" target="_blank">greg@gregorycollins.net</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 dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</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"><span><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 dir="ltr"><div class="gmail_extra">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.</div></div></blockquote><div><br></div></span><div>The way things are shaping up, we've had 17 years of rock solid stability</div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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. </div></div></div></div></blockquote><div><br></div><div>I definitely agree here. </div><div><br></div><div>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. </div><div><br><div>Heck, every release I wind up having to change whatever code I have that uses template-haskell or Typeable.</div><br></div><div>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.</div><div> <br></div><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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</div></div></div></div></blockquote><div><br></div><div>I personally don't care about the return side of the equation. <br><br><div>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.</div><div><br></div>I'd personally readily sacrifice "progress" there in the interest of harmony. Herbert as haskell-prime chair possibly feels differently.</div><div> </div><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>and ">> could be slightly more efficient for some monads" is pretty weak sauce.</div></div></div></div></blockquote><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>-Edward</div></div></div></div>