Re: Proposal: Add conspicuously missing Functor instances for tuples

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