Proposal: Remove the bogus MonadFail instance for ST

Thu Mar 15 01:49:39 UTC 2018

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.

On Wed, Mar 14, 2018 at 6:47 PM, Tikhon Jelvis <tikhon at jelv.is> wrote:

> 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.
>
> 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.
>
> On Wed, Mar 14, 2018 at 10:19 AM, Dan Burton <danburton.email at gmail.com>
> wrote:
>
>> 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?
>>
>>
>> To wit:
>>
>> One possible "well behaved" intuition could be "cannot result in an
>>> exception thrown from pure code without usage of unsafe functions."
>>
>>
>> +1
>>
>> -- Dan Burton
>>
>> On Wed, Mar 14, 2018 at 10:06 AM, Simon Peyton Jones via Libraries <
>> libraries at haskell.org> wrote:
>>
>>> 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?
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of *Michael
>>> Snoyman
>>> *Sent:* 14 March 2018 14:31
>>> *To:* Ryan Scott <ryan.gl.scott at gmail.com>
>>> *Cc:* Haskell Libraries <libraries at haskell.org>
>>> *Subject:* Re: Proposal: Remove the bogus MonadFail instance for ST
>>>
>>>
>>>
>>> One possible "well behaved" intuition could be "cannot result in an
>>> exception thrown from pure code without usage of unsafe functions." By this
>>> definition:
>>>
>>>
>>>
>>> * Maybe's fail is well behaved: using `fail "foo"` results in a total
>>> Nothing value
>>>
>>> * List's: same thing, but with an empty list
>>>
>>> * IO: runtime exception, but the exception is _not_ in pure code, but
>>> rather from within IO, where exceptions are always to be expected
>>>
>>> * ST: `runST (fail "foo")` results in a pure value which, when
>>> evaluated, throws a runtime exception, breaking the well behaved definition
>>>
>>> * Identity: `Identity (fail "foo")` can only be a pure value which
>>> throws an exception, and is therefore not well behaved
>>>
>>>
>>>
>>> Note that I added the requirement of "without usage of unsafe
>>> functions," since `unsafePerformIO (fail "foo")` can result in a pure
>>> bottom value.
>>>
>>>
>>>
>>> On Wed, Mar 14, 2018 at 4:25 PM, Ryan Scott <ryan.gl.scott at gmail.com>
>>> wrote:
>>>
>>> Thanks, that makes more sense. I'm inclined to agree that MonadFail
>>> instances should fail in a "well-behaved" way. (I wish I knew how to
>>> make the phrase "well-behaved" more formal, but I don't.) It might be
>>> worth adding this intuition to the Haddocks for MonadFail.
>>>
>>> That being said, one thing to consider before removing this instance
>>> is that there will be some breakage. Ben Gamari added this instance in
>>> [1] because apparently the regex-tdfa package needed it. Other than
>>> that, though, I don't have any real objections to removing this
>>> instance.
>>>
>>> Ryan S.
>>> -----
>>> [1] https://phabricator.haskell.org/D3982
>>>
>>>
>>> On Wed, Mar 14, 2018 at 9:58 AM, David Feuer <david.feuer at gmail.com>
>>> wrote:
>>> > I expect a MonadFail instance to have a well-behaved notion of failure
>>> > within the monad. An exception from "pure" code (which is what ST
>>> > simulates) is not that. On the other hand, perhaps you're right and
>>> > the instance should be removed for IO as well; I don't have as strong
>>> > a sense of revulsion, but maybe users should be forced to be explicit
>>> > with throwIO.
>>> >
>>> > On Wed, Mar 14, 2018 at 9:46 AM, Ryan Scott <ryan.gl.scott at gmail.com>
>>> wrote:
>>> >> OK. You used the phrase "utterly contrary to the purpose of
>>> >> MonadFail", so I'm trying to figure out exactly what you mean here.
>>> >> Prima facie, the purpose of MonadFail (at least, as explained in its
>>> >> Haddocks) is to provide a type class–directed way of desugaring
>>> >> partial pattern matches in do-notation. With this in mind, the current
>>> >> MonadFail instance for ST doesn't seem too offensive.
>>> >>
>>> >> However, I think you have some additional property in mind that you
>>> >> feel the MonadFail ST instance runs afoul of. Do you mind explaining
>>> >> in further detail what this is? (I'm not trying to be snarky here—I
>>> >> genuinely don't know what you're getting at.)
>>> >>
>>> >> Ryan S.
>>> >>
>>> >> On Wed, Mar 14, 2018 at 9:41 AM, David Feuer <david.feuer at gmail.com>
>>> wrote:
>>> >>> I am not. I think that instance is fairly legitimate, as it raises an
>>> >>> IO exception that can be caught in IO. IO's Alternative instance is a
>>> >>> bit shadier, but that's not a topic for this proposal either. ST is
>>> an
>>> >>> entirely different story, and I'm sorry I accidentally mixed it in.
>>> >>>
>>> >>> On Wed, Mar 14, 2018 at 9:05 AM, Ryan Scott <ryan.gl.scott at gmail.com>
>>> wrote:
>>> >>>> It's worth noting that the MonadFail instance for IO [1] also
>>> simply throws
>>> >>>> an error (by way of failIO). Are you proposing we remove this
>>> instance as
>>> >>>> well?
>>> >>>>
>>> >>>> Ryan S.
>>> >>>> -----
>>> >>>> [1]
>>> >>>> http://git.haskell.org/ghc.git/blob/cb6d8589c83247ec96d5faa8
>>> 2df3e93f419bbfe0:/libraries/base/Control/Monad/Fail.hs#l80
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Libraries mailing list
>>> >>>> Libraries at haskell.org
>>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>> >>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180314/b02ba9b1/attachment-0001.html>