<div dir="auto"><div>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. :)</div><div dir="auto"><br></div><div dir="auto">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?).</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, 4 Apr 2019, 4.29 Eric Seidel, <<a href="mailto:eric@seidel.io">eric@seidel.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
On Wed, Apr 3, 2019, at 18:40, Carter Schonwald wrote:<br>
> supporting checking if code uses some (org / team / project) policy of <br>
> "class X with Type T" linting/checking/warning as some sort of <br>
> plugin/warning flag def would be useful. <br>
> <br>
> I think we'd want to warn on the use site of the combination when that <br>
> flag is set, rather on the definition site<br>
> <br>
> a sort of "-fWarnSubtleInstanceUsage" thats off by default and would <br>
> take pairs of class and type names?<br>
> <br>
> are we collectively saying the objections come down to visibility of <br>
> tracking down a "whys this size calculuation always 1, am i going <br>
> insane" bug?<br>
> <br>
> or is the issue moreso that length is a constant / fixed size for <br>
> tuple, and this acts unexpected in nested data structures?<br>
> <br>
> <br>
> to reiterate ,my perspective is: +1 from me, one of the people who are <br>
> concerned about the user impact should contribute a not in -wall <br>
> linting/checking flag that warns on tuple invocations of length from <br>
> foldable as the motivating use of some new warning pragma that can <br>
> support other opt in examples. let someone who wants that warning for <br>
> (,) contribute it, lets not let it block having instances for higher <br>
> arity tuples.<br>
> <br>
> i realize "go write the patch" might be a strong (or sometimes even <br>
> toxic) stance to take, but caring about an issue personally is the best <br>
> motivator, and it sounds like the fundamental problem already exists <br>
> with stuff already in base! adding these instances does not change the <br>
> existence of the issue thats the root of the mild controversy here. it <br>
> already exists, give us tools to make it easier for users to suss out ! <br>
> <br>
> let the higher tuples have their instances! :) <br>
> <br>
> On Wed, Apr 3, 2019 at 11:30 AM <<a href="mailto:amindfv@gmail.com" target="_blank" rel="noreferrer">amindfv@gmail.com</a>> wrote:<br>
> > <br>
> > <br>
> > El 3 abr 2019, a las 02:59, Sven Panne <<a href="mailto:svenpanne@gmail.com" target="_blank" rel="noreferrer">svenpanne@gmail.com</a>> escribió:<br>
> > <br>
> >> A strong -1 from me for the exact same reasons given 2 years ago: <a href="https://mail.haskell.org/pipermail/libraries/2017-March/027883.html" rel="noreferrer noreferrer" target="_blank">https://mail.haskell.org/pipermail/libraries/2017-March/027883.html</a> Nothing has changed since then, we don't even have a warning flag yet (see #11796). Just 2 remarks:<br>
> >> <br>
> >>  * "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.<br>
> >> <br>
> > <br>
> > 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.<br>
> > <br>
> > I'd also very much appreciate work on the compiler flag for warning on an instance!<br>
> > <br>
> > Tom<br>
> > _______________________________________________<br>
> >  Libraries mailing list<br>
> > <a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div></div>