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

Am 13.08.2013 23:34, schrieb John Wiegley:

...

...

...

...

...

MightyByte 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.