Deprecate Foldable for Either

[David Feuer]

Yes. I completely agree that the goal of being able to import
Data.Foldable unqualified was the wrong goal from the start. That goal
is sensible for Data.Traversable, I think, since Traversable has very
few methods and since instances are sufficiently constrained to
prevent *most* of these problems. But it falls apart for
Data.Foldable, which is too "wild". I for one would be quite happy to
banish the lion's share of Foldable operations back to Data.Foldable,
so the Prelude would re-export only  Data.Foldable (Foldable
(foldMap)), and Data.List would export only list-specific functions.

On Fri, Mar 3, 2017 at 10: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.
>
> We could change either of these causes: Change what is exported from Prelude or Remove the instance (and both are breaking compatibility). As a consequence, I find going from "uses of concat(/length/maximum/..) may be confusing/cause bugs" to "we need to remove the instance" to be a weak conclusion.
>
> Further, if don't overlook something, removing an instance (or removing a particular method from an instance) always would create at least as much trouble as changing what is exported from the Prelude would, as the types of concat/length/maximum/.. would necessarily change as a consequence of the former. So to all those arguing in favour of removing methods/instances: What does removing/prohibiting instances give in addition to a change to the type of concat(/length/..) as included unqualified in the default Prelude? In this direction, I have not seen any convincing arguments. (And sorry, I have not read all messages in the previous discussions - it was a bit too much to read for too little general enlightenment.)
>
>
> (My solution is to use custom Preludes for personal projects with exclusively qualified imports, e.g. List.length :: [a] -> Int and Foldable.length :: Foldable t => t a -> Int. Works well, but I see the issues that a custom Prelude is yet another hurdle for beginners.)
>
> -- lennart
>
>
>
> On 02/03/17 17:22, Andreas Abel wrote:
>> Today a student came to me wondering why a certain function produced a regular result, where he had expected an error.  Turned out he had used `concat`, but not on a lists of lists as he had thought, but on a lists of `Either a [b]`.
>>
>> With the Foldable instance for Either, which considers Either a b to be a container of 0-1 elements of b, errors are happily swallowed.
>>
>> I think this instance is harmful and should be deprecated (and later removed) from base.
>>
>> There are similarly pointless Foldable instances as well.
>>
>> See a discussion one year ago, which was heated, but had no consequences.
>>
>> https://mail.haskell.org/pipermail/libraries/2016-February/026678.html
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries