Re: Constraints on definition of `length` should be strengthened

Sven Panne writes:

2017-04-05 18:18 GMT+02:00 Ben Franksen :

...

And let's not forget Either which IMO should be regarded as an unbiased choice. I don't have a proposal for the name, though.

In the dark ages of Haskell's library design, i.e. a long, long time ago, in a distant past, the time where people could actually write significant code without using at least 20 LANGUAGE pragmas ;-), we discussed this already, see e.g. the thread starting at http://code.haskell.org/~dons/haskell-1990-2000/msg07215.html. The final outcome was: Although something like Error/OK would have been better than Left/Right, a slight majority preferred to give a bias to Either. The reasoning was that using "Right" for a "wrong" outcome (i.e. failure) would be a bit obscure, and there was already quite some code using it in the way we still do today. The bias is even explicitly documented in the Haddock docs for Data.Either for ages, so it would not be very wise to change the meaning here after roughly 2 decades.

I guess this means that Haskell has failed to sufficiently avoid success. If a mistake in library design is bad enough (not necessarily the case for Either, but arguably so), it should be corrected even after 20 years.

Of course the question remains: What is the totally unbiased standard sum type for 2 alternatives?

What are you asking? It sounds like an invitation to bikeshed! In general, though, types such as (,) and Either should be used very sparingly. In many cases it would be better to define a new type for the specific purpose. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk