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