Add missing Monad/Traversable instances to tuples

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Add missing Monad/Traversable instances to tuples

Fumiaki Kinoshita
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Edward Kmett-2
I'm +1 on this on the grounds we established a few years back of adding unambigously defined instances where they are well determined.

I've gone to reach for a couple of these before being stymied by their absence in the past and had to build local data types or, worse, inflict orphans on my users.

-Edward

On Tue, Apr 2, 2019 at 12:29 AM Fumiaki Kinoshita <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Henning Thielemann
In reply to this post by Fumiaki Kinoshita

On Tue, 2 Apr 2019, 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.

I think we discussed such instances at length in the past. Unfortunately,
I cannot find the old discussion. At least here is a reddit discussion:
    https://www.reddit.com/r/haskell/comments/3oq0kd/proposal_eliminate_the_monad_implementation_on/

If I would use such an instance in my code this would be an accident and a
programming error. That's why I would want to have instance warnings
first:
    https://gitlab.haskell.org/ghc/ghc/issues/11796


Btw. what happened to GHC-Trac? Now I need JavaScript to see the comments.
:-(
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Ganesh Sittampalam
In reply to this post by Fumiaki Kinoshita
On 02/04/2019 04:28, 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)

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.

Cheers,

Ganesh


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Matthew Pickering
In reply to this post by Fumiaki Kinoshita
For all the reasons in the old thread -1 from me.

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

The main benefit I can see is the small amount of convenience for a
few people, as the expense of potential bugs for any user who returns
multiple values from a function.

If you want to traverse or fold a contain with one element and two
additional data parameters then it is simple to define a newtype for
this purpose which can be `coerce`ed to for no cost.

newtype Data3 a b c = Data3 (a, b, c)

The argument about "adding all unambiguous instances" is not well
motivated or adhered to, for example, there is no Num instance for
functions.

Cheers,

Matt


On Tue, Apr 2, 2019 at 5:29 AM Fumiaki Kinoshita <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Artyom Kazak-2
In reply to this post by Fumiaki Kinoshita
+0.1 from me.

These instances are awful but at least let's be consistent. 


On Tue, Apr 2, 2019, 06:29 Fumiaki Kinoshita <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Niklas Hambüchen
In reply to this post by Matthew Pickering
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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Francesco Ariis
In reply to this post by Henning Thielemann
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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Eric Mertens
In reply to this post by Fumiaki Kinoshita
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
Eric Mertens

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Ruben Astudillo
In reply to this post by Ganesh Sittampalam
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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Carter Schonwald
In reply to this post by Eric Mertens
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
Eric Mertens
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

George Wilson
I'm also +1 on this for the consistency reasons mentioned.

Cheers,
George

On Wed, 3 Apr 2019 at 12:27, Carter Schonwald
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>>
>> --
>> Eric Mertens
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Sven Panne-2
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.

   * I am not sure if consistent nonsense is better than partial nonsense. :-/  (For a weaker formulation: sed 's/nonsense/surprising behavior/g')

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Fumiaki Kinoshita
In reply to this post by Fumiaki Kinoshita
Fine, let's forget about Foldable instances. What about Monad and Traversable?

2019年4月2日(火) 13:28 Fumiaki Kinoshita <[hidden email]>:
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

M Farkas-Dyck
On 02/04/2019, Fumiaki Kinoshita <[hidden email]> wrote:
> Fine, let's forget about Foldable instances. What about Monad and
> Traversable?

Traversable requires Foldable.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

amindfv
In reply to this post by Sven Panne-2


El 3 abr 2019, a las 02:59, Sven Panne <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Carter Schonwald
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 <[hidden email]> wrote:


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

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Eric Seidel-3
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 <[hidden email]> wrote:
> >
> >
> > El 3 abr 2019, a las 02:59, Sven Panne <[hidden email]> 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Bryan Richter-2
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, <[hidden email]> 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 <[hidden email]> wrote:
> >
> >
> > El 3 abr 2019, a las 02:59, Sven Panne <[hidden email]> 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Add missing Monad/Traversable instances to tuples

Henning Thielemann

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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
12