Add missing Monad/Traversable instances to tuples

[Eric Seidel]

I'm similarly concerned about the potential for these instances to introduce subtle bugs like those introduced by the Foldable/Traversable proposal. But I think your two explanations are one and the same. The instances behave in counter-intuitive ways, and as a result they lead to confusing and hard-to-diagnose bugs.

I understand the desire for consistency, and that there are some cases where the instances are useful. I think there's a compromise where we add the instances alongside the ability to warn about or blacklist instances that you don't want GHC to use. But until we have the latter, I can't support this proposal.

On Wed, Apr 3, 2019, at 18:40, Carter Schonwald wrote:
> supporting checking if code uses some (org / team / project) policy of 
> "class X with Type T" linting/checking/warning as some sort of 
> plugin/warning flag def would be useful. 
> 
> I think we'd want to warn on the use site of the combination when that 
> flag is set, rather on the definition site
> 
> a sort of "-fWarnSubtleInstanceUsage" thats off by default and would 
> take pairs of class and type names?
> 
> are we collectively saying the objections come down to visibility of 
> tracking down a "whys this size calculuation always 1, am i going 
> insane" bug?
> 
> or is the issue moreso that length is a constant / fixed size for 
> tuple, and this acts unexpected in nested data structures?
> 
> 
> to reiterate ,my perspective is: +1 from me, one of the people who are 
> concerned about the user impact should contribute a not in -wall 
> linting/checking flag that warns on tuple invocations of length from 
> foldable as the motivating use of some new warning pragma that can 
> support other opt in examples. let someone who wants that warning for 
> (,) contribute it, lets not let it block having instances for higher 
> arity tuples.
> 
> i realize "go write the patch" might be a strong (or sometimes even 
> toxic) stance to take, but caring about an issue personally is the best 
> motivator, and it sounds like the fundamental problem already exists 
> with stuff already in base! adding these instances does not change the 
> existence of the issue thats the root of the mild controversy here. it 
> already exists, give us tools to make it easier for users to suss out ! 
> 
> let the higher tuples have their instances! :) 
> 
> On Wed, Apr 3, 2019 at 11:30 AM <amindfv at gmail.com> wrote:
> > 
> > 
> > El 3 abr 2019, a las 02:59, Sven Panne <svenpanne at gmail.com> escribió:
> > 
> >> A strong -1 from me for the exact same reasons given 2 years ago: https://mail.haskell.org/pipermail/libraries/2017-March/027883.html Nothing has changed since then, we don't even have a warning flag yet (see #11796). Just 2 remarks:
> >> 
> >>  * "Doesn't break existing code" is an invalid argument: Removing e.g. type checking won't break existing code, either, but this is probably not a worthy goal. And the proposal goes a step towards removing type checking in a very subtle way.
> >> 
> > 
> > Another strong -1 from me for exactly this reason. I've seen too many bugs where a datatype was changed and suddenly e.g. "length" was being called with a ([x], y) instead of a [x], and we're without warning returning 1 every time.
> > 
> > I'd also very much appreciate work on the compiler flag for warning on an instance!
> > 
> > Tom
> > _______________________________________________
> >  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
>