<div dir="auto">That seems reasonable. But I wonder if pattern matching failure in IO do should be allowed to slip by silently, or whether we should exclude the otherwise-reasonable instance to catch more mistakes.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mar 14, 2018 10:31 AM, "Michael Snoyman" <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>One possible "well behaved" intuition could be "cannot result in an exception thrown from pure code without usage of unsafe functions." By this definition:</div><div><br></div><div>* Maybe's fail is well behaved: using `fail "foo"` results in a total Nothing value</div><div>* List's: same thing, but with an empty list<br></div><div>* IO: runtime exception, but the exception is _not_ in pure code, but rather from within IO, where exceptions are always to be expected</div><div>* ST: `runST (fail "foo")` results in a pure value which, when evaluated, throws a runtime exception, breaking the well behaved definition</div><div>* Identity: `Identity (fail "foo")` can only be a pure value which throws an exception, and is therefore not well behaved</div><div><br></div><div>Note that I added the requirement of "without usage of unsafe functions," since `unsafePerformIO (fail "foo")` can result in a pure bottom value.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 14, 2018 at 4:25 PM, Ryan Scott <span dir="ltr"><<a href="mailto:ryan.gl.scott@gmail.com" target="_blank">ryan.gl.scott@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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" rel="noreferrer" target="_blank">https://phabricator.haskell.or<wbr>g/D3982</a><br>
<div class="m_1295419557095831927HOEnZb"><div class="m_1295419557095831927h5"><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" rel="noreferrer" target="_blank">http://git.haskell.org/ghc.git<wbr>/blob/cb6d8589c83247ec96d5faa8<wbr>2df3e93f419bbfe0:/libraries/<wbr>base/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" rel="noreferrer" 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" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>
</blockquote></div></div>