<div dir="ltr"><div> </div><p style="margin-left:0cm"><span style="font-family:"Calibri",sans-serif"></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span></p>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) -moz-use-text-color -moz-use-text-color;padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:"Calibri",sans-serif" lang="EN-US">From:</span></b><span style="font-size:11pt;font-family:"Calibri",sans-serif" lang="EN-US"> Haskell-Cafe [mailto:<a href="mailto:haskell-cafe-bounces@haskell.org" target="_blank">haskell-cafe-bounces@haskell.org</a>]
<b>On Behalf Of </b>Mike Meyer<br>
<b>Sent:</b> 07 October 2015 00:24<br>
<b>To:</b> Mark Lentczner; Johan Tibell<br>
<b>Cc:</b> Haskell Libraries; haskell cafe; <a href="mailto:haskell-prime@haskell.org" target="_blank">haskell-prime@haskell.org</a> List<br>
<b>Subject:</b> 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`)</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner <<a href="mailto:mark.lentczner@gmail.com" target="_blank">mark.lentczner@gmail.com</a>> wrote:</p>
</div>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<br>
On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel <<a href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>> wrote:</p>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
TLDR: To complete the AMP, turn `Monad(return)` method into a<br>
top-level binding aliasing `Applicative(pure)`.</p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
</p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't.</p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
</p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
A modest proposal:</p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
</p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
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.</p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
</p>
</div>
<div class="gmail_extra"><br><div>On Wed, Oct 7, 2015 at 9:06 PM, Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-GB">
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">I think there are several different conversations going on at once in this thread. I think it’s worth keeping them separate.</span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><snip> <br></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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.</span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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.</span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Simon</span></p>
<p style="margin-left:0cm"><span style="font-family:"Calibri",sans-serif"> </span></p></div></div></blockquote>This whole discussion is tilted towards the software engineering side.<br></div><div>Of course from this side if someone keeps changing the underbelly in small but significant ways that has multiplicative effects on higher levels, people who have to manage the higher affected levels will protest.<br><br></div><div>However I'd like to respectfully submit that the software engineering angle is not the only one; there's also the teaching angle.<br></div><div><br>When the Haskell report first came out in 1990 this dual purpose was very clear in the first paras.<br></div><div>Over years as Haskell has progressed from being an academic language to a 'Real World' one this balance has been lost.<br></div><div>Whether Monads is really rocket science or its just ill-designed misnamed stuff that looks like a mess because no heavy duty vacuum cleaner has been applied, no one knows for sure because there's little pedagogic experience with any alternative 'cleaned out Haskell'.<br><br></div><div>However this is just to point out that that possibility may be there.<br></div><div><br>And from the pedagogic angle Haskell may be neat but functional programming is probably more significant and programming in general even more so.<br></div><div><br>In this respect here are two posts:<br></div><div>Functional Programming TimeLine: <a href="http://blog.languager.org/2015/04/cs-history-1.html" target="_blank">http://blog.languager.org/2015/04/cs-history-1.html</a><br></div><div>and its sequel: <a href="http://blog.languager.org/2015/06/functional-programming-moving-target.html" target="_blank">http://blog.languager.org/2015/06/functional-programming-moving-target.html</a><br>which is a more indepth analysis of FP in ACM curriculum 2013 and how
pedagogic realities that were generally understood some decades ago have
been increasingly forgotten today.<br><br></div><div>For the specific case at hand -- return vs pure -- Ive no specific opinion<br></div><div>However on a wider front, the confusion and frustration of the thousands of beginners who have to see the forbidding meaningless 'Functor' and 'Monad' instead of something more accessible like Mappable/Computational is IMHO a factor for Haskell not getting as much success as it should.<br><br></div><div>Hopefully the community will take spj's call for significant batched-up changes seriously<br></div>
</div></div>