Re: ExceptT vs. EitherT
Henning Thielemann <schlepptop <at> henning-thielemann.de>
2013-08-14 08:49:29 GMT
Am 13.08.2013 23:09, schrieb David Luposchainsky:
> On 2013-08-13 22:57, Gabriel Gonzalez wrote:
>> I don't really see the value in `Except` either, but it's there to
>> satisfy Ross who wants an `Identity`-specialized version of the monad
> I think at this rate, we're running out of terms for "crashing" pretty
> soon. Exception vs. error is bad enough, and now some want to add Except
> to that list.
> On the other hand, EitherT already exists in a current and used library,
> it is very clear what that transformer does, and it goes hand in hand
> with MaybeT.
> Furthermore I think Hennings objections are not very convincing:
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. (Currently I use my own
Exceptional type for that purpose.)
My general concern is that the discussion is focussed on whether an
instance fulfills mathematical laws, but not on software engineering
aspects. Although some types are structurally equivalent (Either and
Except, pair and Writer, function and Reader monad), they have very
different uses. If I want to combine two types in one, I want to express
this by Either. If I want exception handling, I want to express this by
Except. Either should not have a monad instance, and Except should not
have a function like partitionEithers.
A strength of Haskell's type system is safety. Safety means that certain
things are forbidden. In contrast to that, a discussion focussed on
fulfilling mathematical laws tends to allow as much as possible. On the
one hand we encourage people to artificially make types distinct by
newtype wrapping. E.g. we define newtype Id = Id Int, in order to forbid
arithmetic operations that are useless for Id's. On the other hand we
throw together many applications to a single type by defining more and
more instances for base types and base classes. In the long run we end
up with MATLAB semantics: They put so much applications into one type
(complex valued tensors used for bools, reals, complex numbers,
polynomials, matrices, graphs etc.) that you better not touch a working
program, if you want to keep it running.
That said, instance Monad Either and instance Monad (->) already exist.
We cannot remove them easily, because may people rely on them. However,
we can discourage their use and propose the clean way via types from the
transformers package. Then the exception handling monad in
'transformers' should not have a name that resembles "Either", because
its use is very different from a plain union type. For me "Exept" is a
good choice, because the intended application is exception handling.
> - Monad for pairs duplicates Writer, which is existing functionality but
> without the newtype wrapper safety. There is no equivalent for this with
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
> - Num for functions - I have yet to see an example where that is
> beneficial beyond "funny how that works".
I guess that people liked to write sin+cos or 2*exp. If not, there must
be enough other reasons to publish