
I like this argumentation! Consistency is really the most valuable property! Which contra-arguments is?
It is unintuitive { maximum (100,4) == 4; length (1,2) == 1 }
Intuition could be different. If we understand asymmetry of tuple than it is completely natural.
It is hard to explain to students
You don't need to explain it. Tuples are one of the first things to discuss. No classes in scope yet. Later when you go through (Functor, Applicative) to (Foldable, Traversable) there will be no problem.
It is useless
I suppose that use cases are close to use cases for Functor instances.
It provoke to use tuples extensively
I don't think that exactly these instances provoke this.
It can produce errors in runtime
Yes, and so avoid tuples in most cases. These instances just provoke not to use tuples!
What else?
I suppose that either tuples are symmetric and have no Functor instances or
they are assymetric with all consequences.
And there is absolutely no reason to change natural class hierarchy due to
imaginary newbie confusion.
2016-02-25 11:43 GMT+03:00 Index Int
This is getting ridiculous. The main problem with the `Foldable` instance for tuples seems to be that it's asymmetric (takes only the second element into account). Yet tuples are already asymmetric given their `Functor` instance! No one seems to complain about that although for a beginner it's a total WAT (judging from my own experience and people that I explained Haskell to). Why does `succ <$> (1, 2)` evaluate to `(1, 3)` and not `(2, 3)`? Current definitions are entirely consistent, and consistency is the most valuable property.
And given that `Traversable` gives a rise to a `Foldable` similarly to how a `Monad` gives a rise to an `Applicative`, it is the same stupid mistake not to reflect this relation in the type system.
The ship has sailed, but not when the `Foldable` instance defined. It has sailed when the `Functor` instance was defined, everything else is a follow-up. Just get over it already.
On Thu, Feb 25, 2016 at 11:28 AM, Jeremy
wrote: Several suggestions have been made in this thread. The one with the highest cost-to-benefit ratio would seem to be removing the Foldable constraint from Traversable, as it is simply not required by the Traversable definition. Lennart actually tried recompiling base with this "and it hardly needed any changes".
I suggest that we consider this change first, as it brings the benefit of allowing Traversable types without having to define possibly nonsensical Foldable instances, and according to Lennart's experiment, has trivial impact.
Lennart, what changes did you have to make? Anybody care to recompile their pet project with this change and see if there's any significant impact?
-- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Add-conspicuously-missing-Func... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries