Proposal: Add conspicuously missing Functor instances for tuples

David Feuer

18 Jan 2016 18 Jan '16

3:10 p.m.

For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that fmap (+1) (1,2,3) doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following: instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc. I would really love to see these make 8.0.0, but if that's impossible then so be it.

Show replies by date

Andreas Abel

19 Jan 19 Jan

2:41 a.m.

-1 from me. First, I think people should be discouraged from using tuples. Tuples for anything but very short-lived structures (like returning multiple results from a function) make code very unmaintainable. Instead hand-rolled records are the tool of choice, for which you can define your functor instance as you see fit. Second, it is confusing that fmap (+1) (1,2,3) = (1,2,4) while fmap (+1) [1,2,3] = [2,3,4] --Andreas On 18.01.2016 21:10, David Feuer wrote:

...

For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

I would really love to see these make 8.0.0, but if that's impossible then so be it. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

Herbert Valerio Riedel

3:20 a.m.

On 2016-01-18 at 21:10:07 +0100, David Feuer wrote:

...

For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

As stated elsewhere in this thread already, there is the issue about consistency. Here's a relevant section from the Haskell 2010 report[1]:

...

6.1.4 Tuples

...

However, every Haskell implementation must support tuples up to size 15, together with the instances for Eq, Ord, Bounded, Read, and Show.

IMO, we either have no `Functor` instances for tuples at all, or we have them for all tuples up to size 15. The current situations of having them defined only for 2-tuples is inconsistent. Cheers, hvr [1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006...

Carter Schonwald

7:30 a.m.

Agreed. +1 On Tuesday, January 19, 2016, Herbert Valerio Riedel wrote:

...

On 2016-01-18 at 21:10:07 +0100, David Feuer wrote:

...
For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

As stated elsewhere in this thread already, there is the issue about consistency. Here's a relevant section from the Haskell 2010 report[1]:

...
6.1.4 Tuples

...

However, every Haskell implementation must support tuples up to size 15, together with the instances for Eq, Ord, Bounded, Read, and Show.

IMO, we either have no `Functor` instances for tuples at all, or we have them for all tuples up to size 15. The current situations of having them defined only for 2-tuples is inconsistent.

Cheers, hvr

[1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006... _______________________________________________ Libraries mailing list Libraries@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Andrew Butterfield

10:46 a.m.

Of course, the proper/correct "implementation" for "Functor" with tuples should be instance Functor (,) where fmap (f,g) (a,b) = (f a, g b) instance Functor (,,) where fmap (f,g,h) (a,b) = (f a, g b, h c) instance Functor (,,,) where fmap (f,g,h,k) (a,b) = (f a, g b, h c, k d) and so on... (where fmap's type sig alters in a "tuple-structured" way with each instance...) The current instance for (,)a is my fmap(id, f) Or should we have 15 classes ? class Functor... class BiFunctor... class TriFunctor.... ... class QuincadecaFunctor /PentadecaFunctor - depending if you prefer Latin/Greek ;-) This probably doesn't clear anything up but does explain why heavy tuple use is deprecated as per an earlier mail in this thread..... Regards, Andrew

...

On 19 Jan 2016, at 12:30, Carter Schonwald wrote:

Agreed. +1

On Tuesday, January 19, 2016, Herbert Valerio Riedel mailto:hvriedel@gmail.com> wrote: On 2016-01-18 at 21:10:07 +0100, David Feuer wrote:

...
For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

As stated elsewhere in this thread already, there is the issue about consistency. Here's a relevant section from the Haskell 2010 report[1]:

...
6.1.4 Tuples

...

However, every Haskell implementation must support tuples up to size 15, together with the instances for Eq, Ord, Bounded, Read, and Show.

IMO, we either have no `Functor` instances for tuples at all, or we have them for all tuples up to size 15. The current situations of having them defined only for 2-tuples is inconsistent.

Cheers, hvr

[1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006... https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006... _______________________________________________ Libraries mailing list Libraries@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Andrew Butterfield School of Computer Science & Statistics Trinity College Dublin 2, Ireland

Alois Cochard

10:24 a.m.

+1 Agree for consistency, I can also see those instances as being useful in some specific context, even if I agree with Andreas that in general they should be discouraged (especially for newcomers). On 19 January 2016 at 09:20, Herbert Valerio Riedel wrote:

...

On 2016-01-18 at 21:10:07 +0100, David Feuer wrote:

...
For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

As stated elsewhere in this thread already, there is the issue about consistency. Here's a relevant section from the Haskell 2010 report[1]:

...
6.1.4 Tuples

...

However, every Haskell implementation must support tuples up to size 15, together with the instances for Eq, Ord, Bounded, Read, and Show.

IMO, we either have no `Functor` instances for tuples at all, or we have them for all tuples up to size 15. The current situations of having them defined only for 2-tuples is inconsistent.

Cheers, hvr

[1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- *Λ\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

amindfv＠gmail.com

3:32 p.m.

...

El 19 ene 2016, a las 10:24, Alois Cochard escribió:

+1

Agree for consistency, I can also see those instances as being useful in some specific context, even if I agree with Andreas that in general they should be discouraged (especially for newcomers).

Can you give us an example where using e.g. the Functor instance for a 5-tuple would be the correct/best design decision? Tom

...

...
On 19 January 2016 at 09:20, Herbert Valerio Riedel wrote: On 2016-01-18 at 21:10:07 +0100, David Feuer wrote:

...
For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

As stated elsewhere in this thread already, there is the issue about consistency. Here's a relevant section from the Haskell 2010 report[1]:

...
6.1.4 Tuples

...

However, every Haskell implementation must support tuples up to size 15, together with the instances for Eq, Ord, Bounded, Read, and Show.

IMO, we either have no `Functor` instances for tuples at all, or we have them for all tuples up to size 15. The current situations of having them defined only for 2-tuples is inconsistent.

Cheers, hvr

[1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Λ\ois http://twitter.com/aloiscochard http://github.com/aloiscochard _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Alois Cochard

3:54 p.m.

I don't have any use case like that. I'm in favor of this proposal for consistency sake. That last part of my comment about usefulness/discouraging usage was about using Functor instance on tuple in general, no matter the arity. On 19 January 2016 at 21:32, wrote:

...

El 19 ene 2016, a las 10:24, Alois Cochard escribió:

+1

Agree for consistency, I can also see those instances as being useful in some specific context, even if I agree with Andreas that in general they should be discouraged (especially for newcomers).

Can you give us an example where using e.g. the Functor instance for a 5-tuple would be the correct/best design decision?

Tom

On 19 January 2016 at 09:20, Herbert Valerio Riedel wrote:

...
On 2016-01-18 at 21:10:07 +0100, David Feuer wrote:

...
For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

As stated elsewhere in this thread already, there is the issue about consistency. Here's a relevant section from the Haskell 2010 report[1]:

...
6.1.4 Tuples

...

However, every Haskell implementation must support tuples up to size 15, together with the instances for Eq, Ord, Bounded, Read, and Show.

IMO, we either have no `Functor` instances for tuples at all, or we have them for all tuples up to size 15. The current situations of having them defined only for 2-tuples is inconsistent.

Cheers, hvr

[1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- *Λ\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

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

-- *Λ\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

amindfv＠gmail.com

4:04 p.m.

If the only uses we can imagine for these instances are - Cases where it's not a great design decision - Cases where it's used accidentally and results in a silent runtime failure instead of a compile-time error then I'm a strong -1 Tom

...

El 19 ene 2016, a las 15:54, Alois Cochard escribió:

I don't have any use case like that. I'm in favor of this proposal for consistency sake.

That last part of my comment about usefulness/discouraging usage was about using Functor instance on tuple in general, no matter the arity.

...
On 19 January 2016 at 21:32, wrote:

...
El 19 ene 2016, a las 10:24, Alois Cochard escribió:

+1

Agree for consistency, I can also see those instances as being useful in some specific context, even if I agree with Andreas that in general they should be discouraged (especially for newcomers).

Can you give us an example where using e.g. the Functor instance for a 5-tuple would be the correct/best design decision?

Tom

...
...
On 19 January 2016 at 09:20, Herbert Valerio Riedel wrote: On 2016-01-18 at 21:10:07 +0100, David Feuer wrote:

...
For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

As stated elsewhere in this thread already, there is the issue about consistency. Here's a relevant section from the Haskell 2010 report[1]:

...
6.1.4 Tuples

...

However, every Haskell implementation must support tuples up to size 15, together with the instances for Eq, Ord, Bounded, Read, and Show.

IMO, we either have no `Functor` instances for tuples at all, or we have them for all tuples up to size 15. The current situations of having them defined only for 2-tuples is inconsistent.

Cheers, hvr

[1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Λ\ois http://twitter.com/aloiscochard http://github.com/aloiscochard _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Λ\ois http://twitter.com/aloiscochard http://github.com/aloiscochard

David Feuer

4:20 p.m.

The problem, I think, is that 1. Many of us thing the instance for pairs is useful. Some of us think the instance for triples is occasionally useful. Most of us doubt the instances for large tuples are often useful (but I'm not quite convinced). 2. Most of us value consistency very highly. Even if we think the instance for pairs is great and the instance for septuples is silly, we want to have the same answer for all tuple sizes. Thus we have the usual "The axiom of choice is obviously true, the well-ordering principle is obviously false, and who can say about Zorn's lemma." Why I'm not quite convinced about large tuples being entirely silly: people do weird things with Template Haskell. When they do so, they want to be able to use functions as uniformly as possible. A function (fmap) that always hits the last component of a tuple, even if it has 15 components, may be just what they need. On Tue, Jan 19, 2016 at 4:04 PM, wrote:

...

If the only uses we can imagine for these instances are - Cases where it's not a great design decision - Cases where it's used accidentally and results in a silent runtime failure instead of a compile-time error

then I'm a strong -1

Tom

El 19 ene 2016, a las 15:54, Alois Cochard escribió:

I don't have any use case like that. I'm in favor of this proposal for consistency sake.

That last part of my comment about usefulness/discouraging usage was about using Functor instance on tuple in general, no matter the arity.

On 19 January 2016 at 21:32, wrote:

...
El 19 ene 2016, a las 10:24, Alois Cochard escribió:

+1

Agree for consistency, I can also see those instances as being useful in some specific context, even if I agree with Andreas that in general they should be discouraged (especially for newcomers).

Can you give us an example where using e.g. the Functor instance for a 5-tuple would be the correct/best design decision?

Tom

On 19 January 2016 at 09:20, Herbert Valerio Riedel wrote:

...
On 2016-01-18 at 21:10:07 +0100, David Feuer wrote:

...
For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

As stated elsewhere in this thread already, there is the issue about consistency. Here's a relevant section from the Haskell 2010 report[1]:

...
6.1.4 Tuples

...

However, every Haskell implementation must support tuples up to size 15, together with the instances for Eq, Ord, Bounded, Read, and Show.

IMO, we either have no `Functor` instances for tuples at all, or we have them for all tuples up to size 15. The current situations of having them defined only for 2-tuples is inconsistent.

Cheers, hvr

[1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Λ\ois http://twitter.com/aloiscochard http://github.com/aloiscochard

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

-- Λ\ois http://twitter.com/aloiscochard http://github.com/aloiscochard

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

Christopher Allen

4:22 p.m.

...

Why I'm not quite convinced about large tuples being entirely silly:

They happen to be a useful dumb type for things like rows you parse from a csv file or similar as well. Pretty sure the various *-simple database clients use this as well. They are, admittedly, sort of a paradigm case for why `lens` is often more useful than Functors, but Functor isn't going anywhere and there's only one valid instance for these types so they might as well live with the types or the class. On Tue, Jan 19, 2016 at 3:20 PM, David Feuer wrote:

...

The problem, I think, is that

1. Many of us thing the instance for pairs is useful. Some of us think the instance for triples is occasionally useful. Most of us doubt the instances for large tuples are often useful (but I'm not quite convinced). 2. Most of us value consistency very highly. Even if we think the instance for pairs is great and the instance for septuples is silly, we want to have the same answer for all tuple sizes.

Thus we have the usual "The axiom of choice is obviously true, the well-ordering principle is obviously false, and who can say about Zorn's lemma."

Why I'm not quite convinced about large tuples being entirely silly: people do weird things with Template Haskell. When they do so, they want to be able to use functions as uniformly as possible. A function (fmap) that always hits the last component of a tuple, even if it has 15 components, may be just what they need.

...
If the only uses we can imagine for these instances are - Cases where it's not a great design decision - Cases where it's used accidentally and results in a silent runtime failure instead of a compile-time error

then I'm a strong -1

Tom

El 19 ene 2016, a las 15:54, Alois Cochard escribió:

I don't have any use case like that. I'm in favor of this proposal for consistency sake.

That last part of my comment about usefulness/discouraging usage was about using Functor instance on tuple in general, no matter the arity.

On 19 January 2016 at 21:32, wrote:

...
El 19 ene 2016, a las 10:24, Alois Cochard escribió:

+1

Agree for consistency, I can also see those instances as being useful in some specific context, even if I agree with Andreas that in general they should be discouraged (especially for newcomers).

Can you give us an example where using e.g. the Functor instance for a 5-tuple would be the correct/best design decision?

Tom

On 19 January 2016 at 09:20, Herbert Valerio Riedel
...
wrote:

...
On 2016-01-18 at 21:10:07 +0100, David Feuer wrote:

...
For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to

do

...
...
it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

As stated elsewhere in this thread already, there is the issue about consistency. Here's a relevant section from the Haskell 2010 report[1]:

...
6.1.4 Tuples

...

However, every Haskell implementation must support tuples up to size 15, together with the instances for Eq, Ord, Bounded, Read, and Show.

IMO, we either have no `Functor` instances for tuples at all, or we have them for all tuples up to size 15. The current situations of having

On Tue, Jan 19, 2016 at 4:04 PM, wrote: them

...
...
...
defined only for 2-tuples is inconsistent.

Cheers, hvr

[1]:

https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006...

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

-- Λ\ois http://twitter.com/aloiscochard http://github.com/aloiscochard

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

-- Λ\ois http://twitter.com/aloiscochard http://github.com/aloiscochard

_______________________________________________ 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

-- Chris Allen Currently working on http://haskellbook.com

amindfv＠gmail.com

4:50 p.m.

...

El 19 ene 2016, a las 16:22, Christopher Allen escribió:

...
Why I'm not quite convinced about large tuples being entirely silly:

They happen to be a useful dumb type for things like rows you parse from a csv file or similar as well. Pretty sure the various *-simple database clients use this as well.

In these cases large tuples are useful, but a Functor instance that operates on the last element?

...

They are, admittedly, sort of a paradigm case for why `lens` is often more useful than Functors, but Functor isn't going anywhere and there's only one valid instance for these types so they might as well live with the types or the class.

My disagreement is only in "might as well": there is a downside to these, so I'd like there to be an upside (that's worth it!). Tom

...

...
On Tue, Jan 19, 2016 at 3:20 PM, David Feuer wrote: The problem, I think, is that

1. Many of us thing the instance for pairs is useful. Some of us think the instance for triples is occasionally useful. Most of us doubt the instances for large tuples are often useful (but I'm not quite convinced). 2. Most of us value consistency very highly. Even if we think the instance for pairs is great and the instance for septuples is silly, we want to have the same answer for all tuple sizes.

Thus we have the usual "The axiom of choice is obviously true, the well-ordering principle is obviously false, and who can say about Zorn's lemma."

Why I'm not quite convinced about large tuples being entirely silly: people do weird things with Template Haskell. When they do so, they want to be able to use functions as uniformly as possible. A function (fmap) that always hits the last component of a tuple, even if it has 15 components, may be just what they need.

On Tue, Jan 19, 2016 at 4:04 PM, wrote:

...
If the only uses we can imagine for these instances are - Cases where it's not a great design decision - Cases where it's used accidentally and results in a silent runtime failure instead of a compile-time error

then I'm a strong -1

Tom

El 19 ene 2016, a las 15:54, Alois Cochard escribió:

I don't have any use case like that. I'm in favor of this proposal for consistency sake.

That last part of my comment about usefulness/discouraging usage was about using Functor instance on tuple in general, no matter the arity.

On 19 January 2016 at 21:32, wrote:

...
El 19 ene 2016, a las 10:24, Alois Cochard escribió:

+1

Agree for consistency, I can also see those instances as being useful in some specific context, even if I agree with Andreas that in general they should be discouraged (especially for newcomers).

Can you give us an example where using e.g. the Functor instance for a 5-tuple would be the correct/best design decision?

Tom

On 19 January 2016 at 09:20, Herbert Valerio Riedel wrote:

...
On 2016-01-18 at 21:10:07 +0100, David Feuer wrote:

...
For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

As stated elsewhere in this thread already, there is the issue about consistency. Here's a relevant section from the Haskell 2010 report[1]:

...
6.1.4 Tuples

...

However, every Haskell implementation must support tuples up to size 15, together with the instances for Eq, Ord, Bounded, Read, and Show.

IMO, we either have no `Functor` instances for tuples at all, or we have them for all tuples up to size 15. The current situations of having them defined only for 2-tuples is inconsistent.

Cheers, hvr

[1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Λ\ois http://twitter.com/aloiscochard http://github.com/aloiscochard

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

-- Λ\ois http://twitter.com/aloiscochard http://github.com/aloiscochard

_______________________________________________ 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

-- Chris Allen Currently working on http://haskellbook.com

Matthew Pickering

4:35 p.m.

To directly answer the initial proposal, there seems to be little harm in functor instances for n-tuples. Functor instances are usually ok as one must always provide two arguments to fmap which agree with each other. There is little chance of using the wrong instance by accident. However, I am strongly against adding foldable and traversable instances for n-tuples. I thank Ryan for articulating why he finds them useful but due to the pervasive use of tuples to return multiple values from functions I find even the 2-tuple instance distasteful . It is very easy to introduce bugs when refactoring with the existence of these instances. If altering a function which returns a useful foldable such as lists to return a pair then if you ever call length on the returned value then you have introduced a difficult to track down bug. Unlike calls to fmap, there is no sanity check to make sure you are using the right instance. If there are other cases where such instances are useful then I would reconsider my position but I find the arguments for (a canonical instance and for consistency) unconvincing. It should not be the case that we propagate bad behaviour for the sake of consistency. I even think Ryan's use case would be better served by a separate datatype for that purpose. On 19 Jan 2016 21:04, wrote:

...

If the only uses we can imagine for these instances are - Cases where it's not a great design decision - Cases where it's used accidentally and results in a silent runtime failure instead of a compile-time error

then I'm a strong -1

Tom

El 19 ene 2016, a las 15:54, Alois Cochard escribió:

I don't have any use case like that. I'm in favor of this proposal for consistency sake.

That last part of my comment about usefulness/discouraging usage was about using Functor instance on tuple in general, no matter the arity.

On 19 January 2016 at 21:32, wrote:

...
El 19 ene 2016, a las 10:24, Alois Cochard escribió:

+1

Agree for consistency, I can also see those instances as being useful in some specific context, even if I agree with Andreas that in general they should be discouraged (especially for newcomers).

Can you give us an example where using e.g. the Functor instance for a 5-tuple would be the correct/best design decision?

Tom

On 19 January 2016 at 09:20, Herbert Valerio Riedel wrote:

...
On 2016-01-18 at 21:10:07 +0100, David Feuer wrote:

...
For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

As stated elsewhere in this thread already, there is the issue about consistency. Here's a relevant section from the Haskell 2010 report[1]:

...
6.1.4 Tuples

...

However, every Haskell implementation must support tuples up to size 15, together with the instances for Eq, Ord, Bounded, Read, and Show.

IMO, we either have no `Functor` instances for tuples at all, or we have them for all tuples up to size 15. The current situations of having them defined only for 2-tuples is inconsistent.

Cheers, hvr

[1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- *Λ\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

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

-- *Λ\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

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

Alexander Berntsen

20 Jan 20 Jan

7:48 a.m.

...

I'm in favor of this proposal for consistency sake. As am I. Inconsistency seems like laziness at best, and poorly thought

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 19/01/16 21:54, Alois Cochard wrote: through at worst. - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWn4IFAAoJENQqWdRUGk8Bbs4P/RVit2hXVpWn6AaK+zgA8KOA pHyzK93KY+ASLbaWEzsMYwtoreYY1/Rd+xby1St35QGiJm6gEr+LME2LWfWITOur GlPrAWUps/TqipA49JioVKMMOwqub6mcVXisLZt8DGe84pZNarzZXUBh5FGblkGm tZg2tsNT9QEUjodAVi0yf1P+wHNaDz9XaX8/upKMYjkW4tZyeldMky+HBvwBJ8XM feQ3tOTK5dgHPM0ssmUIAVIlL1z0VUmJ6skSNBfQotkCnQRE3uHFagXsCPMGe7gV 9jvLJ1ZHLXFWdS3KtT2UMUzmdQPmygwWCc9jOWZsJr4ndoKBKYConmmYs+Vzvy2x xKqDrHVuKOcEgOOkTHSdXnsw6Wdjs0N9Vw5mc+zFeymf9NoWJeqgijKfInS+jR0b yNYYoVILFY22ISua89dRws0+Ky9gCWkKIbu/+uCteFlXoMv3j60LnmUuoZ3kY+bp H5+c4v3sEObjItbYsRLEo6KiACC1I1bhFJm16+XipAgY0N31R4R9Hr6sCo+yWa2l 9bNJn8KJ/p9N2JZMRUzo2KVwet9VpGq9PP90DDuwf+Nz3xYttWGIUFRgec7OzmHo lYfUWqAtbOP0XguprV2fbxb9Ye3JF0RdqlVoRJCtAlppEkqmu0w8NEt3Uye+ZTkq 2FQ1Dqbh8LiC9dZXNuSD =Cep6 -----END PGP SIGNATURE-----

Oliver Charles

7:50 a.m.

I'm not sure I even want to propose this, but if you're going to make it consistent for all tuples, should you also make Bifunctor consistent for all tuples? On Wed, Jan 20, 2016 at 12:48 PM Alexander Berntsen wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

...
I'm in favor of this proposal for consistency sake. As am I. Inconsistency seems like laziness at best, and poorly thought

On 19/01/16 21:54, Alois Cochard wrote: through at worst.

- -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2

iQIcBAEBCgAGBQJWn4IFAAoJENQqWdRUGk8Bbs4P/RVit2hXVpWn6AaK+zgA8KOA pHyzK93KY+ASLbaWEzsMYwtoreYY1/Rd+xby1St35QGiJm6gEr+LME2LWfWITOur GlPrAWUps/TqipA49JioVKMMOwqub6mcVXisLZt8DGe84pZNarzZXUBh5FGblkGm tZg2tsNT9QEUjodAVi0yf1P+wHNaDz9XaX8/upKMYjkW4tZyeldMky+HBvwBJ8XM feQ3tOTK5dgHPM0ssmUIAVIlL1z0VUmJ6skSNBfQotkCnQRE3uHFagXsCPMGe7gV 9jvLJ1ZHLXFWdS3KtT2UMUzmdQPmygwWCc9jOWZsJr4ndoKBKYConmmYs+Vzvy2x xKqDrHVuKOcEgOOkTHSdXnsw6Wdjs0N9Vw5mc+zFeymf9NoWJeqgijKfInS+jR0b yNYYoVILFY22ISua89dRws0+Ky9gCWkKIbu/+uCteFlXoMv3j60LnmUuoZ3kY+bp H5+c4v3sEObjItbYsRLEo6KiACC1I1bhFJm16+XipAgY0N31R4R9Hr6sCo+yWa2l 9bNJn8KJ/p9N2JZMRUzo2KVwet9VpGq9PP90DDuwf+Nz3xYttWGIUFRgec7OzmHo lYfUWqAtbOP0XguprV2fbxb9Ye3JF0RdqlVoRJCtAlppEkqmu0w8NEt3Uye+ZTkq 2FQ1Dqbh8LiC9dZXNuSD =Cep6 -----END PGP SIGNATURE----- _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Edward Kmett

8:07 a.m.

On Wed, Jan 20, 2016 at 7:50 AM, Oliver Charles wrote:

...

I'm not sure I even want to propose this, but if you're going to make it consistent for all tuples, should you also make Bifunctor consistent for all tuples?

The Bifunctor instances are already defined out to 7-tuples or so. -Edward

...

On Wed, Jan 20, 2016 at 12:48 PM Alexander Berntsen wrote:

...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

...
I'm in favor of this proposal for consistency sake. As am I. Inconsistency seems like laziness at best, and poorly thought

On 19/01/16 21:54, Alois Cochard wrote: through at worst.

- -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2

iQIcBAEBCgAGBQJWn4IFAAoJENQqWdRUGk8Bbs4P/RVit2hXVpWn6AaK+zgA8KOA pHyzK93KY+ASLbaWEzsMYwtoreYY1/Rd+xby1St35QGiJm6gEr+LME2LWfWITOur GlPrAWUps/TqipA49JioVKMMOwqub6mcVXisLZt8DGe84pZNarzZXUBh5FGblkGm tZg2tsNT9QEUjodAVi0yf1P+wHNaDz9XaX8/upKMYjkW4tZyeldMky+HBvwBJ8XM feQ3tOTK5dgHPM0ssmUIAVIlL1z0VUmJ6skSNBfQotkCnQRE3uHFagXsCPMGe7gV 9jvLJ1ZHLXFWdS3KtT2UMUzmdQPmygwWCc9jOWZsJr4ndoKBKYConmmYs+Vzvy2x xKqDrHVuKOcEgOOkTHSdXnsw6Wdjs0N9Vw5mc+zFeymf9NoWJeqgijKfInS+jR0b yNYYoVILFY22ISua89dRws0+Ky9gCWkKIbu/+uCteFlXoMv3j60LnmUuoZ3kY+bp H5+c4v3sEObjItbYsRLEo6KiACC1I1bhFJm16+XipAgY0N31R4R9Hr6sCo+yWa2l 9bNJn8KJ/p9N2JZMRUzo2KVwet9VpGq9PP90DDuwf+Nz3xYttWGIUFRgec7OzmHo lYfUWqAtbOP0XguprV2fbxb9Ye3JF0RdqlVoRJCtAlppEkqmu0w8NEt3Uye+ZTkq 2FQ1Dqbh8LiC9dZXNuSD =Cep6 -----END PGP SIGNATURE----- _______________________________________________ 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

Oliver Charles

8:49 a.m.

Right, and people here are talking about adding Functor for up to 15-tuples, unless I misread. On Wed, Jan 20, 2016 at 1:07 PM Edward Kmett wrote:

...

On Wed, Jan 20, 2016 at 7:50 AM, Oliver Charles wrote:

...
I'm not sure I even want to propose this, but if you're going to make it consistent for all tuples, should you also make Bifunctor consistent for all tuples?

The Bifunctor instances are already defined out to 7-tuples or so.

-Edward

...
On Wed, Jan 20, 2016 at 12:48 PM Alexander Berntsen wrote:

...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

...
I'm in favor of this proposal for consistency sake. As am I. Inconsistency seems like laziness at best, and poorly thought

On 19/01/16 21:54, Alois Cochard wrote: through at worst.

- -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2

iQIcBAEBCgAGBQJWn4IFAAoJENQqWdRUGk8Bbs4P/RVit2hXVpWn6AaK+zgA8KOA pHyzK93KY+ASLbaWEzsMYwtoreYY1/Rd+xby1St35QGiJm6gEr+LME2LWfWITOur GlPrAWUps/TqipA49JioVKMMOwqub6mcVXisLZt8DGe84pZNarzZXUBh5FGblkGm tZg2tsNT9QEUjodAVi0yf1P+wHNaDz9XaX8/upKMYjkW4tZyeldMky+HBvwBJ8XM feQ3tOTK5dgHPM0ssmUIAVIlL1z0VUmJ6skSNBfQotkCnQRE3uHFagXsCPMGe7gV 9jvLJ1ZHLXFWdS3KtT2UMUzmdQPmygwWCc9jOWZsJr4ndoKBKYConmmYs+Vzvy2x xKqDrHVuKOcEgOOkTHSdXnsw6Wdjs0N9Vw5mc+zFeymf9NoWJeqgijKfInS+jR0b yNYYoVILFY22ISua89dRws0+Ky9gCWkKIbu/+uCteFlXoMv3j60LnmUuoZ3kY+bp H5+c4v3sEObjItbYsRLEo6KiACC1I1bhFJm16+XipAgY0N31R4R9Hr6sCo+yWa2l 9bNJn8KJ/p9N2JZMRUzo2KVwet9VpGq9PP90DDuwf+Nz3xYttWGIUFRgec7OzmHo lYfUWqAtbOP0XguprV2fbxb9Ye3JF0RdqlVoRJCtAlppEkqmu0w8NEt3Uye+ZTkq 2FQ1Dqbh8LiC9dZXNuSD =Cep6 -----END PGP SIGNATURE----- _______________________________________________ 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

Edward Kmett

11:03 a.m.

Fair enough, I missed that statement and I have no particular preference on how high the ceiling gets raised beyond 4-5 if somebody else is willing to write the patch. ;) -Edward On Wed, Jan 20, 2016 at 8:49 AM, Oliver Charles wrote:

...

Right, and people here are talking about adding Functor for up to 15-tuples, unless I misread.

On Wed, Jan 20, 2016 at 1:07 PM Edward Kmett wrote:

...
On Wed, Jan 20, 2016 at 7:50 AM, Oliver Charles wrote:

...
I'm not sure I even want to propose this, but if you're going to make it consistent for all tuples, should you also make Bifunctor consistent for all tuples?

The Bifunctor instances are already defined out to 7-tuples or so.

-Edward

...
On Wed, Jan 20, 2016 at 12:48 PM Alexander Berntsen < alexander@plaimi.net> wrote:

...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

...
I'm in favor of this proposal for consistency sake. As am I. Inconsistency seems like laziness at best, and poorly thought

On 19/01/16 21:54, Alois Cochard wrote: through at worst.

- -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2

iQIcBAEBCgAGBQJWn4IFAAoJENQqWdRUGk8Bbs4P/RVit2hXVpWn6AaK+zgA8KOA pHyzK93KY+ASLbaWEzsMYwtoreYY1/Rd+xby1St35QGiJm6gEr+LME2LWfWITOur GlPrAWUps/TqipA49JioVKMMOwqub6mcVXisLZt8DGe84pZNarzZXUBh5FGblkGm tZg2tsNT9QEUjodAVi0yf1P+wHNaDz9XaX8/upKMYjkW4tZyeldMky+HBvwBJ8XM feQ3tOTK5dgHPM0ssmUIAVIlL1z0VUmJ6skSNBfQotkCnQRE3uHFagXsCPMGe7gV 9jvLJ1ZHLXFWdS3KtT2UMUzmdQPmygwWCc9jOWZsJr4ndoKBKYConmmYs+Vzvy2x xKqDrHVuKOcEgOOkTHSdXnsw6Wdjs0N9Vw5mc+zFeymf9NoWJeqgijKfInS+jR0b yNYYoVILFY22ISua89dRws0+Ky9gCWkKIbu/+uCteFlXoMv3j60LnmUuoZ3kY+bp H5+c4v3sEObjItbYsRLEo6KiACC1I1bhFJm16+XipAgY0N31R4R9Hr6sCo+yWa2l 9bNJn8KJ/p9N2JZMRUzo2KVwet9VpGq9PP90DDuwf+Nz3xYttWGIUFRgec7OzmHo lYfUWqAtbOP0XguprV2fbxb9Ye3JF0RdqlVoRJCtAlppEkqmu0w8NEt3Uye+ZTkq 2FQ1Dqbh8LiC9dZXNuSD =Cep6 -----END PGP SIGNATURE----- _______________________________________________ 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

Edward Kmett

19 Jan 19 Jan

6:31 p.m.

Let's do a 3-tuple because it doesn't require any contortions to find a real usecase. type Lens s t a b = forall f. Functor f => (a -> f b) -> s -> f t if you want to return two results from a lens, by picking f = (,,) result1 result2 you can pass it a function a -> (result1, result2, b) and you'll get a function s -> (result1, result2, t) which modifies the structure using the supplied function and gives back both results and the final answer. You could of course make up a completely one-off data type with local instances and a ton of boilerplate. You could play games with nesting tuples, and get worse operational behavior and have an extra bottom and indirection to concern yourself with. Or you could just use the only possible instance we can put on a 3-tuple for Functor. -Edward On Tue, Jan 19, 2016 at 3:32 PM, wrote:

...

El 19 ene 2016, a las 10:24, Alois Cochard escribió:

+1

Agree for consistency, I can also see those instances as being useful in some specific context, even if I agree with Andreas that in general they should be discouraged (especially for newcomers).

Can you give us an example where using e.g. the Functor instance for a 5-tuple would be the correct/best design decision?

Tom

On 19 January 2016 at 09:20, Herbert Valerio Riedel wrote:

...
On 2016-01-18 at 21:10:07 +0100, David Feuer wrote:

...
For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

As stated elsewhere in this thread already, there is the issue about consistency. Here's a relevant section from the Haskell 2010 report[1]:

...
6.1.4 Tuples

...

However, every Haskell implementation must support tuples up to size 15, together with the instances for Eq, Ord, Bounded, Read, and Show.

IMO, we either have no `Functor` instances for tuples at all, or we have them for all tuples up to size 15. The current situations of having them defined only for 2-tuples is inconsistent.

Cheers, hvr

[1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- *Λ\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

_______________________________________________ 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

Edward Kmett

9:38 a.m.

+1 from me. We routinely supply instances for tuples of up to 4 or 5 elements elsewhere. There is no need to be randomly inconsistent here. -Edward On Mon, Jan 18, 2016 at 3:10 PM, David Feuer wrote:

...

For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

I would really love to see these make 8.0.0, but if that's impossible then so be it. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Henning Thielemann

17 Feb 17 Feb

6:15 a.m.

On Tue, 19 Jan 2016, Edward Kmett wrote:

...

+1 from me. We routinely supply instances for tuples of up to 4 or 5 elements elsewhere.

There are only liftA2 and liftA3 (supporting only (,) and (,,), respectively), how little is this? :-) I like consistency, too, and thus propose to remove all Functor, Foldable, Traversable, Applicative instances from all tuples.

Andreas Abel

18 Feb 18 Feb

9:44 a.m.

+1. On 17.02.2016 12:15, Henning Thielemann wrote:

...

I like consistency, too, and thus propose to remove all Functor, Foldable, Traversable, Applicative instances from all tuples.

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

Kosyrev Serge

10:11 a.m.

Andreas Abel writes:

...

+1.

On 17.02.2016 12:15, Henning Thielemann wrote:

...
I like consistency, too, and thus propose to remove all Functor, Foldable, Traversable, Applicative instances from all tuples.

Is there really a convincing case for these instances -- at all? The confusion and the inevitable bug potential, that they create, seem to overwhelm any potential usefulness that comes to my imagination. But maybe someone feels differently? -- с уважениeм / respectfully, Косырев Сергей

Benno Fünfstück

10:28 a.m.

Oftentimes, I will order my tuples in such a way that the "interesting" value comes last in the tuple. The `Traversable` and `Functor` instances are useful in this case, because I use the tuple as `(extraInfo, realValue)`, and mostly I'm only concerned with `realValue` and the `Traversable` and `Functor` instances let me work with `realValue` quite easily. Kosyrev Serge <_deepfire@feelingofgreen.ru> schrieb am Do., 18. Feb. 2016 um 16:11 Uhr:

...

Andreas Abel writes:

...
+1.

On 17.02.2016 12:15, Henning Thielemann wrote:

...
I like consistency, too, and thus propose to remove all Functor, Foldable, Traversable, Applicative instances from all tuples.

Is there really a convincing case for these instances -- at all?

The confusion and the inevitable bug potential, that they create, seem to overwhelm any potential usefulness that comes to my imagination.

But maybe someone feels differently?

-- с уважениeм / respectfully, Косырев Сергей _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Henning Thielemann

23 Feb 23 Feb

3:11 a.m.

On Thu, 18 Feb 2016, Benno Fünfstück wrote:

...

Oftentimes, I will order my tuples in such a way that the "interesting" value comes last in the tuple. The `Traversable` and `Functor` instances are useful in this case, because I use the tuple as `(extraInfo, realValue)`, and mostly I'm only concerned with `realValue` and the `Traversable` and `Functor` instances let me work with `realValue` quite easily.

If you put effort into the right ordering of pair members, you could as well put your effort into defining a custom type: data ExtraInfo info a = ExtraInfo info a This would be much clearer.

Edward Kmett

18 Feb 18 Feb

10:35 a.m.

I very much feel differently. The Functor instance has been around for a decade and is actually fairly heavily used. It is necessary to support the Applicative for (,) e, which is the anonymous writer monad, like (->) e is the anonymous reader monad, which has also been around for over a decade. Traversable's sequence gives you canonical distributive law for this functor. sequence :: (e, f a) -> f (e, a) The (,) e functor is by far the most common choice of functor for things like lenses to be instantiated with. forall f. Functor f => (a -> f b) -> s -> f t becomes (a -> (e, b)) -> s -> (e, t) giving you a secondary result when you want it. Saying that a bifunctor is Hask*Hask -> Hask doesn't quite work in haskell, but we can say that it is a functor to a functor category: Hask -> [Hask, Hask]. For (,) to be a bifunctor, (,) e should be a functor, or that notion falls apart as (,) e isn't a functor in the functor category. The list goes on. -Edward On Thu, Feb 18, 2016 at 10:11 AM, Kosyrev Serge <_deepfire@feelingofgreen.ru

...

wrote:

...

Andreas Abel writes:

...
+1.

On 17.02.2016 12:15, Henning Thielemann wrote:

...
I like consistency, too, and thus propose to remove all Functor, Foldable, Traversable, Applicative instances from all tuples.

Is there really a convincing case for these instances -- at all?

The confusion and the inevitable bug potential, that they create, seem to overwhelm any potential usefulness that comes to my imagination.

But maybe someone feels differently?

-- с уважениeм / respectfully, Косырев Сергей

Manuel Gómez

10:41 a.m.

On Thu, Feb 18, 2016 at 11:05 AM, Edward Kmett wrote:

...

The Functor instance has been around for a decade and is actually fairly heavily used.

It is necessary to support the Applicative for (,) e, which is the anonymous writer monad, like (->) e is the anonymous reader monad, which has also been around for over a decade.

Traversable's sequence gives you canonical distributive law for this functor.

sequence :: (e, f a) -> f (e, a)

The (,) e functor is by far the most common choice of functor for things like lenses to be instantiated with.

forall f. Functor f => (a -> f b) -> s -> f t

becomes (a -> (e, b)) -> s -> (e, t) giving you a secondary result when you want it.

FWIW, as anecdotes have been requested, I use all of these extensively in production, especially that particular usage of sequence.

Henning Thielemann

23 Feb 23 Feb

3:16 a.m.

On Thu, 18 Feb 2016, Edward Kmett wrote:

...

Traversable's sequence gives you canonical distributive law for this functor.

sequence :: (e, f a) -> f (e, a)

I have my own functions Func.mapFst, Func.mapSnd. This seems to better reflect the symmetry of the pair members. They only need (Functor f), not (Applicative f) like 'sequence' does. http://code.haskell.org/~thielema/utility/src/Control/Functor/HT.hs

Henning Thielemann

17 Feb 17 Feb

6:23 a.m.

On Tue, 19 Jan 2016, Edward Kmett wrote:

...

+1 from me.

Btw. just a few days before I changed the type synonym type Interval t a = ((t,t), a) in my current project to a custom type data Interval t a = Interval (t,t) a because I found that I frequently change the 'a' value. I had to define a Functor instance, but I intentionally excluded the Foldable instance that came with pairs. In return I could replace several unspecific 'fst's and 'snd's by the more specific record field selectors of 'Interval'. Using custom records really pays off.

Conal Elliott

23 Feb 23 Feb

1:54 p.m.

Strongly +1 from me. I very highly value instances of standard type classes for standard type constructions, particularly products, sums, and functions, not just for some library wrappers around them. And consistency usually ends up the best practical choice, whether or not many uses are clear beforehand. On Tue, Jan 19, 2016 at 6:38 AM, Edward Kmett wrote:

...

+1 from me.

We routinely supply instances for tuples of up to 4 or 5 elements elsewhere.

There is no need to be randomly inconsistent here.

-Edward

On Mon, Jan 18, 2016 at 3:10 PM, David Feuer wrote:

...
For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that

fmap (+1) (1,2,3)

doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following:

instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc.

I would really love to see these make 8.0.0, but if that's impossible then so be it. _______________________________________________ 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

3375

Age (days ago)

3411

Last active (days ago)

List overview

Download

29 comments

18 participants

participants (18)

Alexander Berntsen
Alois Cochard
amindfv＠gmail.com
Andreas Abel
Andreas Abel
Andrew Butterfield
Benno Fünfstück
Carter Schonwald
Christopher Allen
Conal Elliott
David Feuer
Edward Kmett
Henning Thielemann
Herbert Valerio Riedel
Kosyrev Serge
Manuel Gómez
Matthew Pickering
Oliver Charles