Add missing Monad/Traversable instances to tuples

[George Wilson]

I'm also +1 on this for the consistency reasons mentioned.

Cheers,
George

On Wed, 3 Apr 2019 at 12:27, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
>
> 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 <emertens at gmail.com> wrote:
>>
>> 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 <fumiexcel at gmail.com> 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 at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>>
>> --
>> Eric Mertens
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries