
The concerns are valid, but
1) adding these (the only possible / most general instances) will not break
any existing code
2) cannot break any existing code except that which uses orphan instances
(which will always break,so it doesnt matter)
3) brings better consistency, especially since bitraversable has the same
instances?
also: i feel like some of the concerns brought up here really are about
either
a) more desugaring for Tuples as Sized Lists? aka, i mean Hlist 3 a , when
i write the type (a,a,a) ?
//
i've seen bugs in "production" from using the Maybe Monoid in a data
aggregation (space leaks are the best!), that doesn't make the Maybe
monoid of a semigroup any less useful!
so from my perspective, while yes, some folks use tuples for fixed size
homogenuous collections, they are useful powerful tools in the algebra of
types and functional programming jiggery pokery! There is no sound reason
to cripple our official prepresentative of the the simple polymorphic
product type formal, the "*" of our haskell and the eternal dual of the sum
of our cases! ;)
strong +1, let the algebras roar :)
to be clear, the arguments against are valid, but i thnk they could be
addressed by identifying the changes / tooling that would enable a better
fitting of intent. buggy code happens, fix the root, not the symptom
On Tue, Apr 2, 2019 at 12:00 PM Eric Mertens
Hi libraries@,
I'm also -1 on these instances. I'd prefer to see that the various tuples have instances that don't privilege one type variable over another. I find the existing instances for 2-tuples are already more likely to be used in error than intentionally, and even when used intentionally turn heads with their surprising behavior. I'd prefer to have Writer from transformers used, for example, when the non-symmetric treatment of the type parameters is intended.
Best regards, Eric Mertens
On Mon, Apr 1, 2019 at 9:29 PM Fumiaki Kinoshita
wrote: I submitted https://gitlab.haskell.org/ghc/ghc/merge_requests/644 but it might be still controversial. I'd like to get more opinions again.
Here's the list of proposed instances:
Foldable ((,,) a b) Foldable ((,,,) a b c) Traversable ((,,) a b) Traversable ((,,,) a b c) Functor ((,,) a b) (Monoid a, Monoid b) => Applicative ((,,) a b) (Monoid a, Monoid b) => Monad ((,,) a b) Functor ((,,,) a b c) (Monoid a, Monoid b, Monoid c) => Applicative ((,,,) a b c) (Monoid a, Monoid b, Monoid c) => Monad ((,,,) a b c)
The absence of Traversable instances for tuples feels quite inconsistent given that there are Bitraversable instances already. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-- Eric Mertens _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries