On Tue, Apr 02, 2019 at 08:53:10AM +0200, Henning Thielemann wrote:

I think we discussed such instances at length in the past. Unfortunately, I cannot find the old discussion.

The discussion should be: https://mail.haskell.org/pipermail/libraries/2017-March/027824.html I recall someone (most likely yourself) sensibly proposing instance warnings before shipping this.

Btw. what happened to GHC-Trac? Now I need JavaScript to see the comments. :-(

Alas, that ship has sailed too: https://gitlab.com/gitlab-org/gitlab-ce/issues/43433 -F

On 02-04-19 03:16, Ganesh Sittampalam wrote:

Presumably these would leave us with things like length (2,3,4) = 1 ?

If so I'm a weak -1; it's awful but the ship has already sailed with pairs, so maybe consistency beats more "wat" moments.

Exactly, this is specially confusing when the tuple is of different types `(a,b)`, as common examples with ghci on `(a,a)` will return the "correct" value for `length`. -1 for me too. -- -- Ruben -- PGP: 4EE9 28F7 932E F4AD

As somebody who's seen stuff like

sum (1,2) 2

sneak into production code, I am also very scared of having more of it. I would be super appreciative of any technical solution that allows those that want these instances to opt into having them, while making it possible to not have them in most business logic code. On 02/04/2019 9:40 AM, Matthew Pickering wrote:

To repeat the main reason: this change introduces bugs into programs which are very hard to detect.

I'm also +1 on this for the consistency reasons mentioned. Cheers, George On Wed, 3 Apr 2019 at 12:27, Carter Schonwald 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 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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Eric Mertens _______________________________________________ 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

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

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

On Thu, 4 Apr 2019, Bryan Richter wrote:

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. :)

In Germany there is a law: If you damage environment in the course of a construction, you must compensate this somehow. E.g. if you fell a tree you must plant some new ones. Analogously, if you reduce type safety in a way then add compensation in another way. That is, I also think that it is the obligation of the instance proposers to also implement some instance warning. I would not be surprised if they find out this way that we have a case of YAGNI.

Hi, Andreas Abel wrote:

Abusing tuples for the writer monad was a bad idea in the first place. There is no need to drive a bad idea further to the bitter end.

Another way to put it:

Not everything that is mathematically consequential is good software engineering practice.

I could not agree more. Except that I hold that the mathematical consequence in this case only makes sense if a very particular perspective is adopted. From other, equally valid, perspectives, sum (2,3) = 3 etc. is simply nonsensical. -1 from me too. And for the record: Ganesh Sittampalam replied replied to Carter Schoenwald:

...

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

For the record I think the root cause here *is* the instances, and anything we do later is just sticking plaster. In my mind the instances are the moral equivalent of using dynamic types.

I fully agree with this too, and if the only purpose of the proposed tooling indeed is to be a "plaster" for users who accidentally get hurt by sharp edges that really should not be there in the first place, then that seems to be not only wholly unnecessary, but a downright dangerous direction. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

I agree with Andreas and Henning's line of reasoning: Add the instances IFF we have warnings for them and can effectively outlaw them in our codebases if we want to. If we take this stance *both *sides of the debate are motivated to add the feature. On Thu, Apr 4, 2019 at 9:45 AM Richard Eisenberg wrote:

On Apr 4, 2019, at 3:12 AM, Andreas Abel wrote:

Not everything that is mathematically consequential is good software engineering practice.

+1 to that -- which means -1 to the proposal.

I might change my mind if the proposal includes the instance warnings, following Henning's reasoning.

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

They are writer monads for sure, but WriterT does not subsume them. If a typeclass method has type Writer w a, it does not allow GeneralizedNewtypeDeriving on it due to the type roles. I don't really have any idea how instance warnings should look like. 2019年4月7日(日) 17:58 Henning Thielemann :

On Sun, 7 Apr 2019, Fumiaki Kinoshita wrote:

...

I removed Foldable/Traversable instances from the patch with reluctance. I'd still like to add these instances:

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)

Still duplicates to the Writer monad.

How about extending the patch by the long needed instance warnings? :-)

On 2019-04-07 4:54 a.m., Fumiaki Kinoshita wrote:

I removed Foldable/Traversable instances from the patch with reluctance. I'd still like to add these instances:

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)

You have a +1 from me. I can't wait to hear the objections to these.