Proposal: Remove the bogus MonadFail instance for ST

[David Feuer]

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.

On Mar 14, 2018 10:31 AM, "Michael Snoyman" <michael at snoyman.com> wrote:

> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180314/33563057/attachment.html>