ExceptT vs. EitherT

[David Luposchainsky]

On 2013-08-14 10:49, Henning Thielemann wrote:

> In all cases I listed you can define an instance that is mathematically
> sound, that is, it fulfills some nice laws. But from the view of a
> programmer, I want additionally safety. I want that programs are
> rejected that are "obviously" wrong.
> 
> Returning to "Either": You can define a monad instance on it that
> fulfills all monad laws, i.e. it is mathematically sound. This instance
> already exist. But for me Either is just a plain set sum, a union type.
> I may use it for lists that may contain two types of elements. I may use
> it for constructing larger sum types without the need to define a new
> 'data'. This is for example useful in GHCi. But then - why should this
> type also be a monad, where the Left and Right are handled very
> differently? When I want to have the exception semantics I prefer to
> make that explicit using the Except type.
>
> [...]
> 
> In transformer the Writer monad could also have been defined as
> 
>   data Writer w a = Writer a w
> 
> and vice versa the Except monad could be defined by
> 
>   newtype Except e a = Except (Either e a)
> 
> I don't think there is a substantial difference. I order to be
> consistent with the current style of type definitions in 'transformers',
> I think the definition will be:
> 
>   newtype ExceptT e m a = ExceptT (m (Either e a))
>   type Except = ExceptT e Identity a

That sounds very convincing (I didn't think making an Either newtype was
up for discussion). I still don't think "ExceptT" makes a very good
name, but that's a negligible issue.

David