Re: Add missing Monad/Traversable instances to tuples

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, 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 wrote:

...

El 3 abr 2019, a las 02:59, Sven Panne 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries