<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">On this issue I totally agree with Ed.
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">J</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Libraries [mailto:libraries-bounces@haskell.org]
<b>On Behalf Of </b>Edward Kmett<br>
<b>Sent:</b> 17 June 2015 14:34<br>
<b>To:</b> David Luposchainsky<br>
<b>Cc:</b> Haskell Libraries; ghc-devs@haskell.org<br>
<b>Subject:</b> Re: MFP updates: ideas worth discussing<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">There is a bit of a knee-jerk reaction that we should go to something simpler than Monad as a superclass constraint for MonadFail, but I think most of those reasons fall apart or at least lose much of their weight upon deeper inspection.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Ultimately, I'm a not concerned about interactions between ApplicativeDo notation and fail.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Any automatic desugaring into 'fail' will be in a context which is necessarily incurring a monad constraint.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">E.g.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New"">do </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> Just x <- m</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New""> ...</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">has to pick up the Monad constraint anyways to deal with the binding!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This leaves only code that does something like.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New"">foo = x <*> fail y</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">which is hand written to invoke <span style="font-family:"Courier New"">
fail</span>.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Given that the entire "tree" of the Applicative" is available for inspection and that that fail can't depend on any context internal to the Applicative and remain 'just Applicative' I have a hard time foreseeing any real applications lost
by continuing to assume a context of:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New"">class Monad m => MonadFail m</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">and there is a lot of value in the simple context.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Most of the value in ApplicativeDo notation comes from the opportunities for increased parallelism, not so much from the reduced constraints on the resulting code, and as we can see above, it'll never arise during the desguaring in a place
that wouldn't incur a Monad constraint anyways. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Even getting rid of the Monad constraint w/ ApplicativeDo is going to require gymnastics around `return`.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-Edward<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">P.S. On an unrelated note, for the record, I'm very strongly +1 on a MonadFail instance for IO. There we use throwIO explicitly, so it is even able to be handled and caught locally. The set of things you can do in IO is large enough to
support and reason about explicit failure.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">P.P.S. I think if we extend the proposal to include an explicit member of the class for pattern match failure with the code we currently have lurking in the compiler for producing the string from the context, then most of the concerns raised
by folks who would prefer to use a heavier weight -- but vastly harder to standardize -- exception mechanism would also be addressed in practice.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Jun 16, 2015 at 11:07 AM, David Luposchainsky <<a href="mailto:dluposchainsky@googlemail.com" target="_blank">dluposchainsky@googlemail.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
MonadFail proposal update 1<br>
===========================<br>
<br>
<br>
Rendered version of this text:<br>
<a href="https://github.com/quchen/articles/blob/master/monad_fail_update1.md" target="_blank">https://github.com/quchen/articles/blob/master/monad_fail_update1.md</a><br>
<br>
Original MFP:<br>
<a href="https://github.com/quchen/articles/blob/master/monad_fail.md" target="_blank">https://github.com/quchen/articles/blob/master/monad_fail.md</a><br>
<br>
<br>
Short summary<br>
- -------------<br>
<br>
A week has passed since I posted the MFP, and the initial discussion is mostly<br>
over. Here are my observations:<br>
<br>
- - Everyone agrees that `fail` should not be in `Monad`.<br>
- - Almost everyone agrees that it should be thrown out of it.<br>
- - Some would prefer to see the special desugaring be gone entirely.<br>
- - The name `MonadFail` is controversial, because of a potential `Applicative`<br>
constraint.<br>
- - We're still unsure about whether `IO` should get a `MonadFail` instance, but<br>
the bias seems to be towards "yes".<br>
<br>
<br>
<br>
New ideas worth thinking about<br>
- ------------------------------<br>
<br>
### Special desugaring or not<br>
<br>
Johann suggested an optional warning whenever something desugars to use `fail`.<br>
I think that's an idea we should think about. It is easily implemented in the<br>
compiler, and would probably behave similar to -fwarn-unused-do-binds in<br>
practice: notation that is not wrong, but might not be what the programmer<br>
intended.<br>
<br>
<br>
### Errors vs. Exceptions<br>
<br>
Henning is concerned about the confusion between exceptions and programming<br>
errors. In his words,<br>
<br>
> We should clearly decide what "fail" is intended for - for programming<br>
> errors or for exceptions.<br>
<br>
What I see clashing with his point is backwards compatibility. Removing the<br>
`String` argument breaks all explicit invocations of `fail`. Unfortunately,<br>
we're not in a position to break very much. If someone has a better idea I'd<br>
love to hear about it though.<br>
<br>
<br>
### ApplicativeDo<br>
<br>
ApplicativeDo is somewhere out there on the horizon, and we're not sure yet how<br>
much `fail` makes sense in the context of `Applicative`. An Applicative<br>
computation is statically determined in its shape, so it either always or never<br>
fails. Depending on previous results would introduce the `Monad` constraint<br>
anyway.<br>
<br>
<br>
<br>
Probing status<br>
- --------------<br>
<br>
Henning has started to look at the impact of the proposal when explicit<br>
invocations of `fail` are considered as well, something I have not done in my<br>
original survey. Luckily, things don't look too bad, Lens and its forest of<br>
dependencies can be fixed in around ten trivial changes, for example.<br>
<br>
<br>
Greetings,<br>
David/quchen<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
<br>
iQEcBAEBAgAGBQJVgDvGAAoJELrQsaT5WQUspmIIAJi9UVYIitHv2CKvWSmk1fg0<br>
hYaPRXDJMnyFS21v57+JeTPhM/dnI4k0guUUrlIB9k5WPaySQ6MKIAnB51o5O9Gv<br>
zt87FII5/oYsJtVPruKgBtLPbJVhg6zGUXmNco1S2wvB5m5HdBooQsiBRY+qiFfZ<br>
MJOdzXpRCrYJk/0PeF7sglBOElSwsSmGq/klvJUo4VeVAdi8bU+lKRfET/AmAAM5<br>
oqckAI0SEaFo+w6EXBLPiL/F5SoFBmKR50Nu4NKWRBcoNGq7AwvWEKDZeU0PvC3a<br>
dykqSnFTRtL5LeWZnByuZTVVqlDG3afjX6ZYkrUbMKQeE9rVf24Gx9jlRusxSds=<br>
=zUDu<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<br clear="both">
This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at <BR>
http://www.standardchartered.com/en/incorporation-details.html<BR>
<BR>
Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx<BR>
<BR>
Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.<BR>
</body>
</html>