Add missing Monad/Traversable instances to tuples

[Bryan Richter]

I also understand the consistency aesthetic, and I would support efforts to
make it feasible. The onus to "write a patch", though, is on the side of
people championing this aesthetic. :)

I would hate to see a quirk of Haskell used as a wedge to further confound
the notion of n-tuples representing singular, compound values (which they
do, right?).

On Thu, 4 Apr 2019, 4.29 Eric Seidel, <eric at seidel.io> wrote:

> 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
> >
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190404/91cda6e5/attachment.html>