Re: Proposal to solve the `EitherT` problem.
Fair point, but then EitherT is too neutral, giving no hint of the purpose of the monad instance, and suggesting a symmetry that is absent from the monad: Right is normal monadic sequencing, while Left is the exceptional control path. Things get particularly 'sinister' when you get to naming the throw and catch combinators. It's a bit like the reason for having Writer instead of using the monad instance for (,). So I'd lean more to something like Except, which would also be in line with Moggi's original presentation of this monat and transformer.
I also think that the monad instances on Either and (,) are abuses. (And
However, there is prior art (i.e. the existing name of `Either`). Using a different name for the monad and the monad transformer seems like bad form to me. This is also a good argument for keeping both monad transformers in `transformers`. `ErrorT` satisfies the people who want a meaningful name and `EitherT` satisfies the people who prefer a neutral purpose. the monad instance on (->), too, since once I got a hard to find error where a missing argument in a function call was interpreted as an instance of the Reader monad.) I think that this position is too extreme. The use of the `Either` monad for error handling is Haskell canon and is more widely understood than even monad transformers. The logical conclusion of what you are proposing is to duplicate all `Either` machinery once for each potential application of `Either`. That's not to say that there shouldn't be isomorphic types with names and behaviors tailored to specific application domains. I understand the perils of "boolean blindness" (and its equivalent for other types). However, there needs to be space in the standard libraries for the neutral approach otherwise you will fragment the library ecosystem considerably.
On Mon, Jun 17, 2013 at 01:14:23PM -0700, Gabriel Gonzalez wrote:
Fair point, but then EitherT is too neutral, giving no hint of the purpose of the monad instance, and suggesting a symmetry that is absent from the monad: Right is normal monadic sequencing, while Left is the exceptional control path. Things get particularly 'sinister' when you get to naming the throw and catch combinators. It's a bit like the reason for having Writer instead of using the monad instance for (,). So I'd lean more to something like Except, which would also be in line with Moggi's original presentation of this monat and transformer.
However, there is prior art (i.e. the existing name of `Either`). Using a different name for the monad and the monad transformer seems like bad form to me.
Indeed having a differents name for the monad and monad transformer was always another of the flaws of ErrorT, but there's another way to fix that, and more in line with the treatment of the other monad transformers (with the exception of MaybeT).
This is also a good argument for keeping both monad transformers in `transformers`. `ErrorT` satisfies the people who want a meaningful name and `EitherT` satisfies the people who prefer a neutral purpose.
Actually it isn't: you've shown that the name Error is too limited and I've shown that Either is too broad.
On Tuesday, June 18, 2013 3:44:07 PM, Ross Paterson wrote:
On Mon, Jun 17, 2013 at 01:14:23PM -0700, Gabriel Gonzalez wrote:
Fair point, but then EitherT is too neutral, giving no hint of the purpose of the monad instance, and suggesting a symmetry that is absent from the monad: Right is normal monadic sequencing, while Left is the exceptional control path. Things get particularly 'sinister' when you get to naming the throw and catch combinators. It's a bit like the reason for having Writer instead of using the monad instance for (,). So I'd lean more to something like Except, which would also be in line with Moggi's original presentation of this monat and transformer.
However, there is prior art (i.e. the existing name of `Either`). Using a different name for the monad and the monad transformer seems like bad form to me.
Indeed having a differents name for the monad and monad transformer was always another of the flaws of ErrorT, but there's another way to fix that, and more in line with the treatment of the other monad transformers (with the exception of MaybeT).
This is also a good argument for keeping both monad transformers in `transformers`. `ErrorT` satisfies the people who want a meaningful name and `EitherT` satisfies the people who prefer a neutral purpose.
Actually it isn't: you've shown that the name Error is too limited and I've shown that Either is too broad.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
I found that the meaning of EitherT was completely obvious to me while I was learning Haskell. Either is always introduced early on as a way to return error values, and so after learning what Monad Transformers are for, EitherT was a natural name. I found ErrorT to be useless as it was too restrictive. Jeff
participants (3)
-
Gabriel Gonzalez -
Jeff Shaw -
Ross Paterson