Deprecate Foldable for Either

[Kris Nuttycombe]

On Fri, Mar 3, 2017 at 8:32 AM, lennart spitzner <lsp at informatik.uni-kiel.de
> wrote:

> (This is a reply to this topic in general, not specific to Andreas'
> suggestion. Also, this argument should generalize well to other Foldable
> methods/instances.)
>
> I don't like the behaviour you observe either. Still the analysis/proposal
> ignores half of the cause - this has been (at least indirectly) pointed out
> repeatedly in this and past threads already, but I'd like to state it
> clearly because people also repeatedly seem to ignore the fact.
>
> In order for the expression `concat (xs :: [Either a [b]])` to be
> accepted, two things need to be the case: Firstly the concat in scope needs
> to be one that is expressed in terms of Foldable. Secondly there needs to
> be a Foldable instance for Either. (Technically it needs to be in scope
> too, but the difference matters only if the instance was an orphan, but
> I'll assume for now that "orphanization" is not the solution.) The first
> reason is of course connected to the design of the default Prelude - which
> I suppose was responsible for getting the specific `concat` into scope here.
>

I think there's an even more fundamental cause that has been stated
implicitly, but not explicitly, in this discussion. Some of us have been
continuing the discussion on Twitter, and I want to recapitulate the
essential points from that exchange here.

In Haskell, Either is the right-biased polymorphic 2-ary sum type;
similarly, '(,)' is the snd-biased polymorphic 2-ary product type. These
biases are, from my perspective at least, a historical artifact that we're
kind of stuck with. @EyalL on Twitter correctly points out that in
retrospect, having Either be unbiased, and having a second, biased type
with 'Terminate' and 'Continue' constructors might have been the better
choice. However, we depend uncritically upon the bias of Either all the
time when we >>= it, so objecting to this bias propagating to its being
Foldable is inconsistent. I personally depend upon the bias of (,) much
less frequently, but I don't assume that gives me any claim to influence
others' use of this bias. If, in days of yore, the semantics of Either and
(,) had been defined to be unbiased, and separate biased versions been
defined, these arguments might have been avoided, and we'd probably see
relatively little use of the unbiased Either and predominant use of the
unbiased (,). Maybe a new language will some day make this choice with the
benefit of hindsight upon the Haskell community's struggles.

Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170303/906857b2/attachment.html>