List monad (Re: Proposal to solve the `EitherT` problem.)

[Henning Thielemann]

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.