<div dir="ltr">Oh, actually, the example I had with >>= violates the law already in place for MonadFail. It would need to look like `handleEmpty x (fail s)` instead, but I think the core idea remains.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 14, 2018 at 6:47 PM, Tikhon Jelvis <span dir="ltr"><<a href="mailto:tikhon@jelv.is" target="_blank">tikhon@jelv.is</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">My intuition for MonadFail is that it lets us fail *in a way that can be handled in the monad*. I'm not sure exactly how to formalize this into a law, so maybe it's not an entirely coherent idea.<div><br></div><div>By this logic, [] is fine because we can write a function `handleEmpty :: a -> [a] -> [a]` such that `fail "" >>= handleEmpty x` is the same as `return x`. The same goes for IO with something built on top of catch. However, this is not true for ST because we can't handle the resulting error without unsafe IO operations.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 14, 2018 at 10:19 AM, Dan Burton <span dir="ltr"><<a href="mailto:danburton.email@gmail.com" target="_blank">danburton.email@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span>I like the sound of Michael’s definition.  Can we document it with the MonadFail class, so that people making instances can find it easily?</span></blockquote><br></span>To wit:<span><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">One possible "well behaved" intuition could be "cannot result in an exception thrown from pure code without usage of unsafe functions."</span></blockquote></span><div><br>+1</div><span class="m_5401718213078396109HOEnZb"><font color="#888888"><input name="virtru-metadata" type="hidden" value="{"email-policy":{"state":"closed","expirationUnit":"days","disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"expires":false,"isManaged":false},"attachments":{},"compose-window":{"secure":false}}"></font></span><div class="gmail_extra"><span class="m_5401718213078396109HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_5401718213078396109m_-732637350965580207gmail_signature" data-smartmail="gmail_signature">-- Dan Burton</div></div></font></span><div><div class="m_5401718213078396109h5">
<br><div class="gmail_quote">On Wed, Mar 14, 2018 at 10:06 AM, Simon Peyton Jones via Libraries <span dir="ltr"><<a href="mailto:libraries@haskell.org" target="_blank">libraries@haskell.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-GB" link="blue" vlink="purple">
<div class="m_5401718213078396109m_-732637350965580207m_-7271120063663277010WordSection1">
<p class="MsoNormal"><span>I like the sound of Michael’s definition.  Can we document it with the MonadFail class, so that people making instances can find it easily?<u></u><u></u></span></p>
<p class="MsoNormal"><span><br>
Simon<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_5401718213078396109_m_-732637350965580207_m_-7271120063663277010__MailEndCompose"><span><u></u> <u></u></span></a></p>
<span></span>
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Libraries [mailto:<a href="mailto:libraries-bounces@haskell.org" target="_blank">libraries-bounces@hask<wbr>ell.org</a>]
<b>On Behalf Of </b>Michael Snoyman<br>
<b>Sent:</b> 14 March 2018 14:31<br>
<b>To:</b> Ryan Scott <<a href="mailto:ryan.gl.scott@gmail.com" target="_blank">ryan.gl.scott@gmail.com</a>><br>
<b>Cc:</b> Haskell Libraries <<a href="mailto:libraries@haskell.org" target="_blank">libraries@haskell.org</a>><br>
<b>Subject:</b> Re: Proposal: Remove the bogus MonadFail instance for ST<u></u><u></u></span></p><div><div class="m_5401718213078396109m_-732637350965580207h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">One possible "well behaved" intuition could be "cannot result in an exception thrown from pure code without usage of unsafe functions." By this definition:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">* Maybe's fail is well behaved: using `fail "foo"` results in a total Nothing value<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">* List's: same thing, but with an empty list<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">* IO: runtime exception, but the exception is _not_ in pure code, but rather from within IO, where exceptions are always to be expected<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">* ST: `runST (fail "foo")` results in a pure value which, when evaluated, throws a runtime exception, breaking the well behaved definition<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">* Identity: `Identity (fail "foo")` can only be a pure value which throws an exception, and is therefore not well behaved<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Note that I added the requirement of "without usage of unsafe functions," since `unsafePerformIO (fail "foo")` can result in a pure bottom value.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Wed, Mar 14, 2018 at 4:25 PM, Ryan Scott <<a href="mailto:ryan.gl.scott@gmail.com" target="_blank">ryan.gl.scott@gmail.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">Thanks, that makes more sense. I'm inclined to agree that MonadFail<br>
instances should fail in a "well-behaved" way. (I wish I knew how to<br>
make the phrase "well-behaved" more formal, but I don't.) It might be<br>
worth adding this intuition to the Haddocks for MonadFail.<br>
<br>
That being said, one thing to consider before removing this instance<br>
is that there will be some breakage. Ben Gamari added this instance in<br>
[1] because apparently the regex-tdfa package needed it. Other than<br>
that, though, I don't have any real objections to removing this<br>
instance.<br>
<br>
Ryan S.<br>
-----<br>
[1] <a href="https://phabricator.haskell.org/D3982" target="_blank">https://phabricator.haskell.or<wbr>g/D3982</a><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
On Wed, Mar 14, 2018 at 9:58 AM, David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br>
> I expect a MonadFail instance to have a well-behaved notion of failure<br>
> within the monad. An exception from "pure" code (which is what ST<br>
> simulates) is not that. On the other hand, perhaps you're right and<br>
> the instance should be removed for IO as well; I don't have as strong<br>
> a sense of revulsion, but maybe users should be forced to be explicit<br>
> with throwIO.<br>
><br>
> On Wed, Mar 14, 2018 at 9:46 AM, Ryan Scott <<a href="mailto:ryan.gl.scott@gmail.com" target="_blank">ryan.gl.scott@gmail.com</a>> wrote:<br>
>> OK. You used the phrase "utterly contrary to the purpose of<br>
>> MonadFail", so I'm trying to figure out exactly what you mean here.<br>
>> Prima facie, the purpose of MonadFail (at least, as explained in its<br>
>> Haddocks) is to provide a type class–directed way of desugaring<br>
>> partial pattern matches in do-notation. With this in mind, the current<br>
>> MonadFail instance for ST doesn't seem too offensive.<br>
>><br>
>> However, I think you have some additional property in mind that you<br>
>> feel the MonadFail ST instance runs afoul of. Do you mind explaining<br>
>> in further detail what this is? (I'm not trying to be snarky here—I<br>
>> genuinely don't know what you're getting at.)<br>
>><br>
>> Ryan S.<br>
>><br>
>> On Wed, Mar 14, 2018 at 9:41 AM, David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br>
>>> I am not. I think that instance is fairly legitimate, as it raises an<br>
>>> IO exception that can be caught in IO. IO's Alternative instance is a<br>
>>> bit shadier, but that's not a topic for this proposal either. ST is an<br>
>>> entirely different story, and I'm sorry I accidentally mixed it in.<br>
>>><br>
>>> On Wed, Mar 14, 2018 at 9:05 AM, Ryan Scott <<a href="mailto:ryan.gl.scott@gmail.com" target="_blank">ryan.gl.scott@gmail.com</a>> wrote:<br>
>>>> It's worth noting that the MonadFail instance for IO [1] also simply throws<br>
>>>> an error (by way of failIO). Are you proposing we remove this instance as<br>
>>>> well?<br>
>>>><br>
>>>> Ryan S.<br>
>>>> -----<br>
>>>> [1]<br>
>>>> <a href="http://git.haskell.org/ghc.git/blob/cb6d8589c83247ec96d5faa82df3e93f419bbfe0:/libraries/base/Control/Monad/Fail.hs#l80" target="_blank">
http://git.haskell.org/ghc.git<wbr>/blob/cb6d8589c83247ec96d5faa8<wbr>2df3e93f419bbfe0:/libraries/ba<wbr>se/Control/Monad/Fail.hs#l80</a><br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> Libraries mailing list<br>
>>>> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">
http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
>>>><br>
______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>

<br>______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>