Constraints on definition of `length` should be strengthened

[Jon Fairbairn]

Sven Panne <svenpanne at gmail.com> writes:

> 2017-04-05 18:18 GMT+02:00 Ben Franksen <ben.franksen at online.de>:
>
>> 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 at cl.cam.ac.uk