Proposal: Remove the bogus MonadFail instance for ST

[David Feuer]

I certainly agree that is not a topic for this proposal.

On Wed, Mar 14, 2018 at 10:38 AM, Michael Snoyman <michael at snoyman.com> wrote:
> I'd favor that decision as well, and could easily tweak my definition of
> well behaved to simply be "no runtime exceptions or bottom values." My only
> recommendation would be to start that as a separate proposal, as there's a
> chance of more opposition to removing the IO instance than the ST instance.
> I'd imagine IO will result in more breakage.
>
> On Wed, Mar 14, 2018 at 4:34 PM, David Feuer <david.feuer at gmail.com> wrote:
>>
>> 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/cb6d8589c83247ec96d5faa82df3e93f419bbfe0:/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
>>>
>>>
>