Constraints on definition of `length` should be strengthened

[Sven Panne]

2017-04-06 9:33 GMT+02:00 Jon Fairbairn <jon.fairbairn at cl.cam.ac.uk>:

> Sven Panne <svenpanne at gmail.com> writes:
> [...] 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.
>

Just to clarify my POV: I didn't want to criticize anything here, I just
wanted to point to some previous discussion. In my POV, Either *is*
intended as a biased sum type (there are tons of more or less standard
libraries which use it that way), while pairs/tuples are intended as
unbiased product types. Of course one can see it in the exact opposite
(still consistent) way, but this wasn't the historical intention, at least
that's my personal interpretation...


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

I think we are in the same boat here, sorry if I didn't make that clear.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170409/7ed110f3/attachment.html>