MonadFail proposal (MFP): Moving fail out of Monad

[Tikhon Jelvis]

+1. This sounds like a good change and, for the most part, doesn't seem all
that painful.

As far as naming goes, perhaps we could make the name refer to do-notation?
Something like DoFail. I mean, that doesn't sound great, but it makes it
clear where fail comes in and how it might apply to non-monad type stuff.
(ApplicativeDo, for example?)

It's also good because nothing about fail is integral to the abstract idea
of a monad or even an applicative. It's a function of convenience to make
pattern matches in do-notation play out better in cases where it's
meaningful.

That's true in the other direction too: nothing about a `fail` function is
particularly tied to monads or even applicatives. A Monad/Applicative
superclass might make the desugaring easier and closer to current behavior,
but the idea of a fail :: String -> f a is broadly applicable to fs that
aren't necessarily either of those.

On Tue, Jun 9, 2015 at 3:42 PM, David Luposchainsky <
dluposchainsky at googlemail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10.06.2015 00:26, Johan Tibell wrote:
> > "As a consequence, in current Haskell, you can not use Monad-polymorphic
> code
> > safely, because although it claims to work for all Monads, it might just
> crash
> > on you. This kind of implicit non-totality baked into the class is
> terrible."
> >
> > Is this actually a problem in practice? Is there any code we can point to
> > that suffers because of the current state of affairs? Could it be
> included in
> > the proposal?
>
> I don't have hard evidence, but the Monad class being partial strikes me as
> pretty backwards in a language where totality and no implicit failures are
> important to the programmers. We try our best to advocate not using certain
> functions like "head" carelessly, but do-notation comes with similar
> partiality.
>
> One concrete example that I know is bimap, but that's something I stumbled
> upon
> months ago by accident. Another is that Binary does not have a monomorphic
> "fail"
> function and it hurts me a bit to use the Monad-"fail" and write a comment
> on how
> that is safe to do in the current context.
>
> I think there are two important consequences of MonadFail. First of all,
> we can
> all safely write failable patterns if we so desire. Second, the compiler
> can
> ensure other people's codebases do not lie to us (knowingly or
> unknowingly).
>
> David/quchen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVd2vEAAoJELrQsaT5WQUs+m8IAOWA9Hd52MG1wZ6g6FoOcXd6
> x64dRDlilmkVu2IRxHADzip75Oji254yKQ5VY9yMGjYpFajtgf0Q8LrmA0ePTzhg
> E/oxdm1vyRoJab1C5TfdrzPM/voP+wHi7y2ak1j0hTNky+wETj4MKtJ/Jef225nd
> APUq05t6nPwzEDCz37RitfbA6/nwwYShaVjNe0tRluPrJuxdBu0+aobFc2lzVL+s
> J7egnV1kqEOhc7INOhWYsvAJPAJSiY950y/Nmxb2/r5orTfN3tsr98d1zwRxhCmq
> UNXhUaj5xD7BK2Rn1Zy7VwUv1T8IRLZuOQrlZh3HWz4t1SI0tTu3tdS468s/B1g=
> =4mEU
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20150609/dbe97ef1/attachment.html>