Monad.fail, was Re: Deprecating fromIntegral

[Jacques Carette]

And pre-dating all of that was a little noticed paper

http://www.cas.mcmaster.ca/~kahl/Publications/Conf/Kahl-Carette-Ji-2006a.html

with a semantics that shows that "pattern matching" is an effect, and 
how to couple that effect with other effects.  It explains the choices 
one sees out there 'in the wild' and augments that with many new options.

Jacques

@InProceedings{Kahl-Carette-Ji-2006a,
   author = 	 {Wolfram Kahl and Jacques Carette and Xiaoheng Ji},
   title = 	 {Bimonadic Semantics for Basic Pattern Matching Calculi},
   crossref =  {MPC2006},
   pages = 	 {253--273}
}

@Proceedings{MPC2006,
   title = {Mathematics of Program Construction, {MPC 2006, Kuressaare, Estonia}},
   booktitle = {Mathematics of Program Construction, {MPC 2006}},
   editor = {Tarmo Uustalu},
   year = 2006,
   publisher = Springer,
   series = LNCS,
   volume = {4014},
   URL = {http://link.springer.de/link/service/series/0558/tocs/t4014.htm}
}


On 2017-09-26 03:46 PM, David Feuer wrote:
> On Tue, Sep 26, 2017 at 2:49 PM, Niklas Hambüchen <mail at nh2.me> wrote:
>
>> It seems that if consensus exists already at a time before, deprecation
>> can be planned ahead of time.
>> The linked page contains examples of that, e.g. the deprecation of
>> `Monad.fail` that is already scheduled for 8.6.
> David Luposchainsky drafted the MonadFail proposal in December 2013,
> nearly four years ago. But that's not the beginning of the story. In
> November 2009, Michael Snoyman wrote, in
> https://wiki.haskell.org/index.php?title=Failure&oldid=31465,
>
>> Fail is referring to the "fail" function, which is part of the Monad typeclass and is almost universally despised.
> And that's not the beginning of the story either. By March 2008, Real
> World Haskell http://book.realworldhaskell.org/read/monads.html
> warning about fail. I don't have the history of the text, but it
> currently reads, in a giant warning box,
>
>> Beware of fail
>>
>> Many Monad instances don't override the default implementation of fail that we show here, so in those monads, fail uses error. Calling error is usually highly undesirable, since it throws an exception that callers either cannot catch or will not expect. Even if you know that right now you're executing in a monad that has fail do something more sensible, we still recommend avoiding it. It's far too easy to cause yourself a problem later when you refactor your code and forget that a previously safe use of fail might be dangerous in its new context.
> In a comment on the text in March 2008, Lennart Augustssen wrote
>
>> The fail function has no business being in the monad class at all, and it should be removed. So I think you should just discourage people from using it in general.
> and the next month Cale Gibbard stated
>
>> [Most] monads can't implement it sensibly, and it's not actually part of the definition of a monad.
>>
>> The fail function was just a hack to make the do-notation translation as described in the Report "simpler", but it really belongs in a separate typeclass, something more along the lines of the way that Haskell 1.4 did it.
> Beginning in February 2008, as
> https://stackoverflow.com/questions/8163852/should-i-avoid-using-monad-fail
> points out, there was a thread,
> http://haskell.1045720.n5.nabble.com/Proposal-Add-Text-Read-maybeRead-Read-a-gt-String-gt-Maybe-a-td3174167.html,
> in which several luminaries spoke out, explicitly or implicitly,
> against fail being in Monad.
>
> So it seems that there was a fairly clear consensus that having fail
> in Monad was a bad idea almost ten years ago, and that it would be
> better to put it in a subclass. It's a bit hard to compare that to the
> case of fromIntegral, which I think people have generally been only
> mildly uncomfortable with, and when we don't know if there is anything
> sufficiently better!
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries