List monad (Re: Proposal to solve the `EitherT` problem.)
Henning Thielemann
schlepptop at henning-thielemann.de
Wed Aug 14 11:20:08 CEST 2013
Am 13.08.2013 23:34, schrieb John Wiegley:
>>>>>> MightyByte <mightybyte at gmail.com> writes:
>
>> I think the discoverability of the name EitherT is huge win given the
>> existing conventions. I think I had even seen ErrorT before MaybeT, but the
>> name obscured its significance for me.
>
> I agree strongly with this point. EitherT is a natural fit in the ecosystem
> of MaybeT, ListT, etc.
To extend my list of abuses: For me the default monad instance for list
is also unfortunate. The monad instance for lists is about combinatorial
programming, others call it non-deterministic programming. But why? It
somehow imposes a duty to define a similar instances for similar data
structures like Streams. But the monad list instance makes no sense on
Streams. On streams you would need a diagonal order of elements.
The Monad list instance must be consistent with the Applicative
instance. There are much more types that allow for an Applicative
instance. Now you are constantly in trouble: If you define a list-like
type like Sequence or NonEmptyList you must think about its possible
Monad and Applicative instances. If there is a Monad instance you are
somehow pushed to make it consistent with the combinatorial Monad List
instance. For a ZipList semantics you must use wrapper then. In contrast
to that, if there cannot be such a Monad instance, you will certainly
define the Applicative instance in a ZipList way instead of omitting the
Applicative instance.
However, whatever you choose you will be inconsistent with some of the
other instances.
This confirms my distinctions between mathematical soundness and
practical uses: The List type allows multiple mathematically sound
Applicative instances. But for deciding on the instance we need to look
at the use of the type.
If I could redesign Prelude I would define "instance Applicative []"
with a ZipList semantics and I would omit the Monad instance. For the
combinatorial programming I would define a newtype wrapper around "[]".
This way I could define different wrapper types for different element
orderings. No ordering would be privileged.
More information about the Libraries
mailing list