+1 it's 2017, hurry up. On Thu, Mar 30, 2017 at 10:51 PM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:

+1, for all the other tuples as well.

On 30 March 2017 at 23:30, Carter Schonwald wrote:

...

Plus one from me

On Mar 23, 2017 6:54 AM, "Fumiaki Kinoshita" wrote:

...

It's surprising that they are missing (forgive me, I'm not here to make people grumpy).

_______________________________________________ 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

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Thu, 30 Mar 2017, Nathan Bouscal wrote:

The argument that people should define custom data types rather than using triples doesn't have any bearing on whether triples should implement these type classes. That argument would imply that whether the type classes are implemented doesn't matter, because if you're complaining about getting unexpected results the response is "use a custom data type",

I don't want unexpected results, I want clear type errors. That's only possible with missing type instances.

On Thu, Mar 30, 2017 at 08:30:32PM +0200, Henning Thielemann wrote:

On Thu, 23 Mar 2017, Fumiaki Kinoshita wrote:

...

It's surprising that they are missing (forgive me, I'm not here to make people grumpy).

I am not surprised because it was discussed at length a year before. I still think all these instances on pairs, triples and other tuples are more dangerous than helpful. It is so easy and much more expressive to define custom data types for your particular application.

I can't help but feel the same way. I find it detrimental that pairs have a Functor instance. I don't care that 'length' is a member of Foldable, or that anything that is a Functor can/should be Foldable —— I just don't know why pairs ever got to Functor. I fear this was an ancient decision... no? My intuition, based on observed usage in Haskell and elsewhere, is that tuples are used as anonymous product types. Thus, I am interested in the rationale for making them Functors because I feel it has denied me a common, valuable tool. I no longer feel that I should use pairs as product types. By making "(,) a" a Functor, it is no longer an anonymous product type —— it is an anonymous Reader. Are anonymous Readers really all that much more valuable than anonymous product types? I cannot conceive it. I must be missing something. And certainly somebody might argue, "Just keep using them as product types. Nothing has changed." But of course something has changed. My product now has a sharp edge. There is some extra information I have to hold in my head: "Don't put this in a Functor context and expect to be able to follow the compiler errors!" If I wanted to hold extra information in my head, surely I would go back to using Perl. I fear that pairs became Functors a long, long time ago, and now we're stuck with it. Is that true? If so, I believe that crucial fact should preface any argument about 'length', and hopefully we could agree the root cause of `length (a,b) == 1` —— if it is to be considered a problem —— is the fact that `fmap f (a,b) == (a, f b)`. For whatever my vote is worth as somebody posting to this list for the first time, -1. Thanks, -Bryan

On Thu, Mar 30, 2017 at 11:18:10PM +0200, Henning Thielemann wrote:

On Thu, 30 Mar 2017, Bryan Richter wrote:

...

My intuition, based on observed usage in Haskell and elsewhere, is that tuples are used as anonymous product types. Thus, I am interested in the rationale for making them Functors because I feel it has denied me a common, valuable tool. I no longer feel that I should use pairs as product types. By making "(,) a" a Functor, it is no longer an anonymous product type —— it is an anonymous Reader. Are anonymous Readers really all that much more valuable than anonymous product types? I cannot conceive it. I must be missing something.

Pairs as functors are Writers. The function type got a Functor instance that corresponds to Readers.

Oops, laziness of the bad sort on my own part. :)

I think the only reason is that some programmers got "laziness" wrong and try to use primitive types for everything instead of using (and importing) dedicated types.

Well, is there anything to be done for it at this point? Is there even any consensus that this was, in retrospect, a poor choice?

re: compiler warnings -- I saw this on reddit a little while back, but I don't think I've seen it in this thread? Worth posting in case anyone missed it: http://blog.ezyang.com/2017/03 On Thu, Mar 30, 2017 at 2:49 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Thu, 30 Mar 2017, Bryan Richter wrote:

On Thu, Mar 30, 2017 at 11:18:10PM +0200, Henning Thielemann wrote:

...

...

I think the only reason is that some programmers got "laziness" wrong and try to use primitive types for everything instead of using (and importing) dedicated types.

Well, is there anything to be done for it at this point? Is there even any consensus that this was, in retrospect, a poor choice?

The community was and is pretty divided, I think. My suggested compromise is to get compiler warnings if you use certain instances (by accident).

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

On Fri, 31 Mar 2017, Sven Panne wrote:

So a reluctant +1 for b), but only *after* we have a flag/pragma. A strong -1 for adding the instances before such a flag/pragma.

Generally we should first have a way to limit damage before adding more type unsafety. Currently re-adding safety belts lags years behind reduction of type safety. Btw. the ticket is https://ghc.haskell.org/trac/ghc/ticket/11796

Next battle: What will be the default for the flag/pragma? >:-)

I'd prefer that this warning is enabled by default. Next best solution is to integrate the warning in Wall. There are people who even find that too annoying. Using the new selective conversion of warnings to errors we can also get back type errors: https://ghc.haskell.org/trac/ghc/ticket/11219

On Sat, Apr 01, 2017 at 07:59:00AM +1000, Tony Morris wrote:

A contrary, consistent position would mean there is a belief in all of the following:

* the length of any value of the type ((,) a) is not 1 * 0 is not an integer

You keep repeating the same message, I wonder if you read the reply that have been sent to you. From the other thread (in which, after a brief threat to fork the compiler, you asked for explanations), Artyom Kazak kindly answered:

Okay, I have to admit that in this particular instance it's not quite my intuition which causes the pain. Or rather, it's a different kind of intuition, which I have acquired from Haskell in particular – "I don't have to be particularly careful about minor refactorings, because if I change the type of one thing, the compiler will tell me what other things I have to change if I want to preserve the logic of my code". The behavior of 'length' breaks this intuition because "I'll just pass a tuple here instead of whatever I used before" stops being a (relatively) safe refactoring.

No mention of it being "categorically invalid". Moreover, the message you are replying to now (by Svan Penne) is clearly illustrates the dichotomy between *type safety* and *consistency*. Surely everyone (despite their ideas and preferred outcome) can see the two competing interests?

The length of ((,) a) is exactly one. Anything else is ridiculous.

Now we are even talking of the length of a function. Can it get more absurd?! It is perfectly to limit the concept of "length" to * linear structures (lists, arrays, etc.) [branching structures do not have a length, they may have a size or maximum depth] * which have variable length [why would you otherwise ask for the length?] Thus, the following answers of ghci are highly questionable, (and for the non-washed brain, simply non-sensical). Prelude> length (Left 100) 0 Prelude> length (Right 200) 1 Just make a field experiment. Go to the mathematics department and ask people what is the length of (1, 1), the length of (1, 1, 1). An then count the number of people that respond "1" to both of these questions. And weight it against the people that say something else. On 01.04.2017 03:27, Tony Morris wrote:

I did read it. I chose not to respond. I do not believe it to be a constructive avenue.

I am repeating myself far less than the misunderstanding and inconsistency around "tuples." To this end, I believe is worthwhile to continue pointing out the inconsistency, and only slightly less so than those who hold a contrary inconsistent position, who are inadvertently pointing out the inconsistency. 0 is not an integer is a statement of equal validity, buit more obviously not so.

If I see "length of tuples", and related misunderstandings and subsequent misrepresentations some number of times, I will respond proportionally. I expect I will see it again in the very near future. I will point to that mistake on the occasion. I hope that is OK.

The length of ((,) a) is exactly one. Anything else is ridiculous. Try arguing against that, instead of a position that does not exist ("length of tuples"). I wrote this instance some number of years ago (about 11), and have used it on teams all over the place. Not once was there an issue that was not quickly corrected, and thereby achieving the practical benefits that come with, by providing a better understanding. That understanding is above. The length of ((,) a) is exactly one. Say it with me.

On 01/04/17 10:08, Francesco Ariis wrote:

...

...

A contrary, consistent position would mean there is a belief in all of the following:

* the length of any value of the type ((,) a) is not 1 * 0 is not an integer You keep repeating the same message, I wonder if you read the reply that have been sent to you. From the other thread (in which, after a brief

On Sat, Apr 01, 2017 at 07:59:00AM +1000, Tony Morris wrote: threat to fork the compiler, you asked for explanations), Artyom Kazak kindly answered:

...

Okay, I have to admit that in this particular instance it's not quite my intuition which causes the pain. Or rather, it's a different kind of intuition, which I have acquired from Haskell in particular – "I don't have to be particularly careful about minor refactorings, because if I change the type of one thing, the compiler will tell me what other things I have to change if I want to preserve the logic of my code". The behavior of 'length' breaks this intuition because "I'll just pass a tuple here instead of whatever I used before" stops being a (relatively) safe refactoring. No mention of it being "categorically invalid".

Moreover, the message you are replying to now (by Svan Penne) is clearly illustrates the dichotomy between *type safety* and *consistency*. Surely everyone (despite their ideas and preferred outcome) can see the two competing interests? _______________________________________________ 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

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www.cse.chalmers.se/~abela/

Hi all,

It is perfectly to limit the concept of "length" to

* linear structures (lists, arrays, etc.) [branching structures do not have a length, they may have a size or maximum depth]

* which have variable length [why would you otherwise ask for the length?]

Just for the record, I could not agree more. Looking up "length", e.g. Merriam-Webster: 1a : the longer or longest dimension of an object What we really are talking about here is counting the number of elements in a data structure. That is clearly applicable to lists as well as trees and tuples interpreted in particular ways. But calling it "length" is not particularly helpful. Nor the effort to reappropriate the very concept of "length" through a categorical interpretation. It would have been a lot better if a name suggesting a sense of counting, or at least a name suggesting that this is something different than the usual length, would have been picked. Maybe elementcount or ever flength. Names matter. /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 send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

In the end, I should be grateful for the FTP. It will provide amusement for years. Q: What is the length of pi? A: Dunno, infinity? Q: And what is the length of just pi? GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> length (Just pi) 1 ROFL. On 01.04.2017 12:32, Ivan Lazar Miljenovic wrote:

On 1 April 2017 at 19:42, Henrik Nilsson wrote:

...

Hi all,

...

It is perfectly to limit the concept of "length" to

* linear structures (lists, arrays, etc.) [branching structures do not have a length, they may have a size or maximum depth]

* which have variable length [why would you otherwise ask for the length?]

Just for the record, I could not agree more.

Looking up "length", e.g. Merriam-Webster:

1a : the longer or longest dimension of an object

What we really are talking about here is counting the number of elements in a data structure. That is clearly applicable to lists as well as trees and tuples interpreted in particular ways.

But calling it "length" is not particularly helpful. Nor the effort to reappropriate the very concept of "length" through a categorical interpretation.

It would have been a lot better if a name suggesting a sense of counting, or at least a name suggesting that this is something different than the usual length, would have been picked. Maybe elementcount or ever flength.

I agree, but on the other hand this should have been done _before_ FTP; at this stage, I lean towards marking this down as one of the known warts of Haskell - possibly with a 3 major version GHC cycle to migrate to a better name once the bikeshedding has been completed - and moving on rather than being revisionist and using this as an excuse to go backwards.

So far, the arguments against these instances that I've seen are:

* The name of the length function is misleading for such instances (with all respect to Tony, agreed; but see above); I don't think I've seen anyone else complain about any of the other function names though.

* Since these classes/instances are now exported from the Prelude, previous code that wouldn't have have type-checked are now valid and thus produce unexpected results (I was against the Prelude export when FTP was being debated, but now - with the possible exception of people learning to program - I think this is a matter of needing to be more aware of the types and using our wonderful REPL environments to test functions rather than blindly just writing code without validating the code logic).

TL;DR: I didn't 100% agree with the way FTP was done precisely due to the problems people have with these instances, but now let's not go backwards (and the tuple instances I've found very useful).

...

Names matter.

/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 send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

_______________________________________________ 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://www.cse.chalmers.se/~abela/

Q: What is the length of pi? A: Dunno, infinity? Q: And what is the length of just pi?

GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> length (Just pi) 1

ROFL.

That is like being surprised about length [1..] and length [[1..]] though. And I imagine nobody would argue that doesn't make sense. I kind of see why people want better name than length but I see no really good argument why the instance is bad. There are no doubt other generalised notions. It also was an unfair question to ask what mathematicians would think the length of (1,1) was. Because the question is not asked in context where we ask about length for the type (a,-) not (-,-). Jakub

...

On 01.04.2017 12:32, Ivan Lazar Miljenovic wrote: On 1 April 2017 at 19:42, Henrik Nilsson wrote:

...

Hi all,

...

It is perfectly to limit the concept of "length" to

* linear structures (lists, arrays, etc.) [branching structures do not have a length, they may have a size or maximum depth]

* which have variable length [why would you otherwise ask for the length?]

Just for the record, I could not agree more.

Looking up "length", e.g. Merriam-Webster:

1a : the longer or longest dimension of an object

What we really are talking about here is counting the number of elements in a data structure. That is clearly applicable to lists as well as trees and tuples interpreted in particular ways.

But calling it "length" is not particularly helpful. Nor the effort to reappropriate the very concept of "length" through a categorical interpretation.

It would have been a lot better if a name suggesting a sense of counting, or at least a name suggesting that this is something different than the usual length, would have been picked. Maybe elementcount or ever flength.

I agree, but on the other hand this should have been done _before_ FTP; at this stage, I lean towards marking this down as one of the known warts of Haskell - possibly with a 3 major version GHC cycle to migrate to a better name once the bikeshedding has been completed - and moving on rather than being revisionist and using this as an excuse to go backwards.

So far, the arguments against these instances that I've seen are:

* The name of the length function is misleading for such instances (with all respect to Tony, agreed; but see above); I don't think I've seen anyone else complain about any of the other function names though.

* Since these classes/instances are now exported from the Prelude, previous code that wouldn't have have type-checked are now valid and thus produce unexpected results (I was against the Prelude export when FTP was being debated, but now - with the possible exception of people learning to program - I think this is a matter of needing to be more aware of the types and using our wonderful REPL environments to test functions rather than blindly just writing code without validating the code logic).

TL;DR: I didn't 100% agree with the way FTP was done precisely due to the problems people have with these instances, but now let's not go backwards (and the tuple instances I've found very useful).

...

Names matter.

/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 send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

_______________________________________________ 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://www.cse.chalmers.se/~abela/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Whily you are correct Jakub, I think it's worse than that. Not only is it like being surpised then length [[1..]] == 1, we also have a kind system, so we can ignore the name. length :: f a -> Int We immediately know that values of the kind (* -> *) slot in to the value (f), with a kind checker to ensure we get it correct. Therefore, we can easily reason about the length of values of kind ((,) a) I do find it hilarious that this discussion continued using the term "tuple" as if to make a reasonable point. KIND ERROR. On 01/04/17 22:00, Jakub Daniel wrote:

...

Q: What is the length of pi? A: Dunno, infinity? Q: And what is the length of just pi?

GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> length (Just pi) 1

ROFL. That is like being surprised about

length [1..]

and

length [[1..]]

though. And I imagine nobody would argue that doesn't make sense. I kind of see why people want better name than length but I see no really good argument why the instance is bad. There are no doubt other generalised notions. It also was an unfair question to ask what mathematicians would think the length of (1,1) was. Because the question is not asked in context where we ask about length for the type (a,-) not (-,-).

Jakub

...

...

On 01.04.2017 12:32, Ivan Lazar Miljenovic wrote: On 1 April 2017 at 19:42, Henrik Nilsson wrote:

...

Hi all,

...

It is perfectly to limit the concept of "length" to

* linear structures (lists, arrays, etc.) [branching structures do not have a length, they may have a size or maximum depth]

* which have variable length [why would you otherwise ask for the length?] Just for the record, I could not agree more.

Looking up "length", e.g. Merriam-Webster:

1a : the longer or longest dimension of an object

What we really are talking about here is counting the number of elements in a data structure. That is clearly applicable to lists as well as trees and tuples interpreted in particular ways.

But calling it "length" is not particularly helpful. Nor the effort to reappropriate the very concept of "length" through a categorical interpretation.

It would have been a lot better if a name suggesting a sense of counting, or at least a name suggesting that this is something different than the usual length, would have been picked. Maybe elementcount or ever flength. I agree, but on the other hand this should have been done _before_ FTP; at this stage, I lean towards marking this down as one of the known warts of Haskell - possibly with a 3 major version GHC cycle to migrate to a better name once the bikeshedding has been completed - and moving on rather than being revisionist and using this as an excuse to go backwards.

So far, the arguments against these instances that I've seen are:

* The name of the length function is misleading for such instances (with all respect to Tony, agreed; but see above); I don't think I've seen anyone else complain about any of the other function names though.

* Since these classes/instances are now exported from the Prelude, previous code that wouldn't have have type-checked are now valid and thus produce unexpected results (I was against the Prelude export when FTP was being debated, but now - with the possible exception of people learning to program - I think this is a matter of needing to be more aware of the types and using our wonderful REPL environments to test functions rather than blindly just writing code without validating the code logic).

TL;DR: I didn't 100% agree with the way FTP was done precisely due to the problems people have with these instances, but now let's not go backwards (and the tuple instances I've found very useful).

...

Names matter.

/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 send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

_______________________________________________ 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://www.cse.chalmers.se/~abela/ _______________________________________________ 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

Join me in not caring about the names. Again, use the types. It's triply hilarious that we have a typed programming language, and an increasingly disproportionate user base who don't know how to use those types. What is this? Amateur hour? Python exists. On 02/04/17 18:22, Henrik Nilsson wrote:

On 04/02/2017 01:56 AM, Tony Morris wrote:

...

length :: f a -> Int

We immediately know that values of the kind (* -> *) slot in to the value (f), with a kind checker to ensure we get it correct. Therefore, we can easily reason about the length of values of kind ((,) a)

I do find it hilarious that this discussion continued using the term "tuple" as if to make a reasonable point. KIND ERROR.

And it's doubly hilarious that that the above argument is put forward without any regard for picking an appropriate name for the concept, which most certainly is very different from "length" as used in everyday parlance, physics, mathematics, and any CS text-book on data-structures and algorithms I've ever seen.

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 send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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

That's fine. You are welcome to believe these things. You are welcome to take offense. You are welcome to believe using types responsibly is "shallow and devoid of substance" or whatever thought might best express this position that I find ridiculous. You are welcome to believe I would benefit by checking credentials. I clearly disagree that using types responsibly is shallow, and I also disagree that I would benefit by "checking credentials." I think it would be yet another waste of time to add to those that have been so strongly recommended. That's perfectly fine. Just keep this amateurism out of my code and we can all carry on. Rather than checking credentials, I instead demand that I work and seek others who are skilled at using types. I will fight to retain this ability. I need to hire people for example. I need to know if they are good at writing code, using types, etc. I think it is fair to fight for this ability, without getting personal, as you have chosen to do. I will continue to fight for this ability regardless. Anyway, programmers often degenerate into this personal ploppety poo. So, cheerio. *eyeroll* On 02/04/17 18:47, Henrik Nilsson wrote:

On 04/02/2017 09:32 AM, Tony Morris wrote:

...

Join me in not caring about the names. Again, use the types.

It's triply hilarious that we have a typed programming language, and an increasingly disproportionate user base who don't know how to use those types. What is this? Amateur hour? Python exists.

I'm sorry, but that's a supremely shallow and entirely polemic argument devoid of any substance whatsoever.

And implying that people like those who initiated this thread are "amateurs" and know nothing about types is both offensive and manifestly unfounded. I suggest you check their credentials if there is any doubt on your part.

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 send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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

It was mostly a joke. Sorry it wasn't understood that way. On 02/04/17 18:54, Theodore Lief Gannon wrote:

Come on guys, let's keep it respectful, especially considering this is the libraries list. Lively debate is good, but it shouldn't turn to noise.

On Apr 2, 2017 1:33 AM, "Tony Morris" mailto:tonymorris@gmail.com> wrote:

Join me in not caring about the names. Again, use the types.

It's triply hilarious that we have a typed programming language, and an increasingly disproportionate user base who don't know how to use those types. What is this? Amateur hour? Python exists.

On 02/04/17 18:22, Henrik Nilsson wrote: > On 04/02/2017 01:56 AM, Tony Morris wrote: >> length :: f a -> Int >> >> We immediately know that values of the kind (* -> *) slot in to the >> value (f), with a kind checker to ensure we get it correct. Therefore, >> we can easily reason about the length of values of kind ((,) a) >> >> I do find it hilarious that this discussion continued using the term >> "tuple" as if to make a reasonable point. KIND ERROR. > > And it's doubly hilarious that that the above argument is put forward > without any regard for picking an appropriate name for the concept, > which most certainly is very different from "length" as used in > everyday parlance, physics, mathematics, and any CS text-book on > data-structures and algorithms I've ever seen. > > 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 send it back to me, and immediately delete it. > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org mailto:Libraries@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Shall we have a big discussion about it? Jeepers creepers mate. Sorry for not apologising correctly. On 03/04/17 11:44, Fumiaki Kinoshita wrote:

Don't think your "joke" made my proposal more convincing or helped anything.

2017-04-02 18:04 GMT+09:00 Tony Morris mailto:tonymorris@gmail.com>:

It was mostly a joke. Sorry it wasn't understood that way.

On 02/04/17 18:54, Theodore Lief Gannon wrote:

...

Come on guys, let's keep it respectful, especially considering this is the libraries list. Lively debate is good, but it shouldn't turn to noise.

On Apr 2, 2017 1:33 AM, "Tony Morris" mailto:tonymorris@gmail.com> wrote:

Join me in not caring about the names. Again, use the types.

It's triply hilarious that we have a typed programming language, and an increasingly disproportionate user base who don't know how to use those types. What is this? Amateur hour? Python exists.

On 02/04/17 18:22, Henrik Nilsson wrote: > On 04/02/2017 01:56 AM, Tony Morris wrote: >> length :: f a -> Int >> >> We immediately know that values of the kind (* -> *) slot in to the >> value (f), with a kind checker to ensure we get it correct. Therefore, >> we can easily reason about the length of values of kind ((,) a) >> >> I do find it hilarious that this discussion continued using the term >> "tuple" as if to make a reasonable point. KIND ERROR. > > And it's doubly hilarious that that the above argument is put forward > without any regard for picking an appropriate name for the concept, > which most certainly is very different from "length" as used in > everyday parlance, physics, mathematics, and any CS text-book on > data-structures and algorithms I've ever seen. > > 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 send it back to me, and immediately delete it. > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org mailto:Libraries@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

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

2017-04-01 12:32 GMT+02:00 Ivan Lazar Miljenovic :

[...] The name of the length function is misleading for such instances (with all respect to Tony, agreed; but see above); I don't think I've seen anyone else complain about any of the other function names though. [...]

OK, hereby I officially complain about the other stuff which makes no sense for tuples: maximum (3,2) => 2 minimum (4,5) => 5 sum (6,7) => 7 product (8,9) => 9 Consistent? Yes. Is it really something you expect? No. Do you want this during refactoring? Definitely not.

El 1 abr 2017, a las 13:45, amindfv@gmail.com escribió:

...

El 1 abr 2017, a las 05:32, Ivan Lazar Miljenovic escribió:

On 1 April 2017 at 19:42, Henrik Nilsson wrote:

...

Hi all,

...

It is perfectly to limit the concept of "length" to

* linear structures (lists, arrays, etc.) [branching structures do not have a length, they may have a size or maximum depth]

* which have variable length [why would you otherwise ask for the length?]

Just for the record, I could not agree more.

Looking up "length", e.g. Merriam-Webster:

1a : the longer or longest dimension of an object

What we really are talking about here is counting the number of elements in a data structure. That is clearly applicable to lists as well as trees and tuples interpreted in particular ways.

But calling it "length" is not particularly helpful. Nor the effort to reappropriate the very concept of "length" through a categorical interpretation.

It would have been a lot better if a name suggesting a sense of counting, or at least a name suggesting that this is something different than the usual length, would have been picked. Maybe elementcount or ever flength.

I agree, but on the other hand this should have been done _before_ FTP; at this stage, I lean towards marking this down as one of the known warts of Haskell - possibly with a 3 major version GHC cycle to migrate to a better name once the bikeshedding has been completed - and moving on rather than being revisionist and using this as an excuse to go backwards.

So far, the arguments against these instances that I've seen are:

* The name of the length function is misleading for such instances (with all respect to Tony, agreed; but see above); I don't think I've seen anyone else complain about any of the other function names though.

* Since these classes/instances are now exported from the Prelude, previous code that wouldn't have have type-checked are now valid and thus produce unexpected results (I was against the Prelude export when FTP was being debated, but now - with the possible exception of people learning to program - I think this is a matter of needing to be more aware of the types and using our wonderful REPL environments to test functions rather than blindly just writing code without validating the code logic).

My concern is not that people should be able to write trivial-to-check code without actually testing it. My concern (because it has happened to me in real code!) is people may write complex functions with difficult-to-inspect results.

The bug that was trickiest to track down was a numerical calculation involving a list whose length was almost always 1, that I performed 'length' on. I wrapped the list in a tuple elsewhere in the code, ghc happily typechecked it, and only in rare cases did I get very weird results. This was deep within a larger calculation, and someone could have easily shipped something like this to production.

Tom

Just to add: I don't think I've experienced bugs like these myself, but maximum (89,88) == 88 and friends seem prime for returning seemingly-correct results while a bug lurks, uncaught by the typechecker. Tom

...

TL;DR: I didn't 100% agree with the way FTP was done precisely due to the problems people have with these instances, but now let's not go backwards (and the tuple instances I've found very useful).

...

Names matter.

/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 send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

By "length" here I mean, the function whose name is lima echo november golf tango hotel. I truly do not care what it is called. Follow the types, and the types of the types. On Thu, Apr 6, 2017 at 12:51 AM, Ben Franksen wrote:

Am 01.04.2017 um 03:27 schrieb Tony Morris:

...

The length of ((,) a) is exactly one. Anything else is ridiculous. Try arguing against that,

Half true: length for this type makes no sense at all since it is not a sequence. So there should be no length defined for it.

Just choose a different name.

Cheers Ben

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

I am not arguing either way on this one. Call it whatever you want, I don't care. I definitely need that function though. Call it pancakes and let's move on. On 06/04/17 17:32, Andreas Abel wrote:

On 06.04.2017 05:15, Tony Morris wrote:

...

By "length" here I mean, the function whose name is lima echo november golf tango hotel. I truly do not care what it is called. Follow the types, and the types of the types.

In theory you are right. But in practice, even a programming language is more than grammar. The names make the vocabulary. There is good names and bad names for a function. Good names are the ones everyone uses. Programmers use several programming languages, and they want the names of analogue functions to be the same. They want to come to a new language and reuse their vocabulary without bad surprises, as much as possible.

Here is a classic short story of Swiss writer Peter Bichsel about an old man, who decides to name a table a "carpet", a bed a "painting" etc.

A Table is a Table http://www.barbarafaessler.com/files/BichselAtableisatable.pdf

The outcome is the expected one...

...

On Thu, Apr 6, 2017 at 12:51 AM, Ben Franksen mailto:ben.franksen@online.de> wrote:

Am 01.04.2017 um 03:27 schrieb Tony Morris: > The length of ((,) a) is exactly one. Anything else is ridiculous. Try > arguing against that,

Half true: length for this type makes no sense at all since it is not a sequence. So there should be no length defined for it.

Just choose a different name.

Cheers Ben

Right, length is particularly unfortunate in that it is a bad example for the purposes of parametricity. We can express additional properties, as well as types, to make up for this shortcoming. Still better than relying on glyphs, which are notoriously unreliable, misleading, inefficient and impratical to use to convey useful information about the behaviour of a function. I will leave out the expression of these properties, so as not to rob anyone of a fun and useful exercise. Ultimately, I genuinely do not care. I routinely work on teams with people who do not care. We use other tools for reasoning about programs; I argue, they are more efficient and reliable. If anyone wants to disagree, that's fine, call it pineapples or whatever may be chosen, and we can all move on. I simply need that function, whatever it might be called. PS: in a dream land, where hardware efficiencies are of no concern, length = fmap (const ()). On 06/04/17 18:12, Henrik Nilsson wrote:

On 04/06/2017 04:15 AM, Tony Morris wrote:

...

By "length" here I mean, the function whose name is lima echo november golf tango hotel. I truly do not care what it is called. Follow the types, and the types of the types.

I think the nub of the matter is that the types (and the types of the types) (in a language like Haskell) actually are not enough. There are (literally) infinitely many functions with the same type as "length". One might argue that few of those make "sense", but that is always going to be a precarious argument unless the setting is made clear.

More generally, if we were to extrapolate and truly refer to things by their full specification, then that would be very cumbersome indeed. By analogy, mathematical theorems are full specifications, and they usually have names.

Names matter, at least to most people (I dare guess), and in particular when we rely on the names to convey missing information, as is the case with "length" given its (Haskell) type.

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 send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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

I don't think it is the "appropriate" set. It's an example. 0 is in the set of integers. The value 0 is in many sets. ((,) a) is the set of things which are Foldable, and consequently, have a length, which reasoning by the type and kind system, immediately leads to the conclusion that it is (very obviously) 1. I am deliberately picking on the argument, "from obviousness", which is the best counter-argument so far (according to the counter-arguers; hoping not to misrepresent here). This is not only a weak argument, I hope we can agree, but *the exact opposite* is true, where we probably disagree. Our premises: Foldable :: (* -> *) -> Constraint length :: forall f. * -> *. f a -> Int let length = foldl (+) 0 -- or similar let f ~ ((,) a) Anything but length=1 for not only not "obvious", but I argue completely ridiculous, by the definition of length. I am not fond of the "argument from obviousness", but if I am forced to use it, I will, and any counter-argument will still fail. PS: I didn't see your original question, sorry. I just stopped looking at the thread for a bit. On 06/04/17 17:28, Jon Fairbairn wrote:

Tony Morris writes:

...

I did read it. I chose not to respond. I do not believe it to be a constructive avenue.

I am repeating myself far less than the misunderstanding and inconsistency around "tuples." To this end, I believe is worthwhile to continue pointing out the inconsistency, and only slightly less so than those who hold a contrary inconsistent position, who are inadvertently pointing out the inconsistency. 0 is not an integer is a statement of equal validity, buit more obviously not so. You keep using “integer”, but didn’t answer my question. What makes you think that integer is the appropriate set? What do the negative numbers represent in this context? If the answer is “nothing”, you are actually talking about natural numbers, and both the sets ℕ and ℕ⁺ are perfectly respectable.

...

The length of ((,) a) is exactly one. Anything else is ridiculous. So that I can understand this, please give an example of a programme where this usage is meaningful.

— Jón

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

These two things are true: * 0 is in the set of integers * ∀ a. ((,) a) is Foldable, and as one of many consequences, the length of all values in the set ∀ a. ((,) a) is 1. There are four possible positions to take on these claims: 1. Both are true. 2. Both are false. 3. The first true and second false. 4. The second true and the first false. I respect arguments 1 and 2. If I chose 1 and you chose 2, I'd say "well rightio then mate and cheers to that", we'd clink glasses and move on. Same if it were vice versa. I do not have the same respect for positions 3 and 4. On 09/04/17 19:48, Jon Fairbairn wrote:

Tony Morris writes:

...

I don't think it is the "appropriate" set. It's an example. 0 is in the set of integers. The value 0 is in many sets. OK, so I clearly do not understand your argument. The implication I took from “and 0 is not an integer” is that the foldable instance for ((,) a) should be present because it is the zero case of something that has integers as its domain, and I wanted to know what that something is. If this was not the intention of your argument, what was?

Genuinely curious: can people point to specific examples in their (or others') code where the ((,) a) instance for Foldable is really helpful and difficult to replace? Tom

El 9 abr 2017, a las 09:29, Benno Fünfstück escribió:

Correct me I I'm wrong but I believe Tony Morris is saying the following:

* not every operation defined for the integers "makes sense" for all integers. Example: '/' does not make sense in the case of 'x / 0' * yet, we still include '0' in the integers even though not every operation makes sense for '0' * -> not every operation in Foldable makes sense for `(,) a` * -> but we also include `0` in the integers, so "not every operation makes sense" is not an argument to exclude `(,) a` from being foldable, just as `0` is not excluded from the integers.

Kind regards, Benno

Tony Morris schrieb am So., 9. Apr. 2017 um 14:26 Uhr:

...

These two things are true:

* 0 is in the set of integers * ∀ a. ((,) a) is Foldable, and as one of many consequences, the length of all values in the set ∀ a. ((,) a) is 1.

There are four possible positions to take on these claims:

1. Both are true. 2. Both are false. 3. The first true and second false. 4. The second true and the first false.

I respect arguments 1 and 2. If I chose 1 and you chose 2, I'd say "well rightio then mate and cheers to that", we'd clink glasses and move on. Same if it were vice versa.

I do not have the same respect for positions 3 and 4.

On 09/04/17 19:48, Jon Fairbairn wrote:

...

Tony Morris writes:

...

I don't think it is the "appropriate" set. It's an example. 0 is in the set of integers. The value 0 is in many sets. OK, so I clearly do not understand your argument. The implication I took from “and 0 is not an integer” is that the foldable instance for ((,) a) should be present because it is the zero case of something that has integers as its domain, and I wanted to know what that something is. If this was not the intention of your argument, what was?

_______________________________________________ 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

I did see those, but was hoping people could provide real code in the context of a library or code solving a particular problem. Real world Haskell, if you will :) Tom

El 9 abr 2017, a las 15:33, Francesco Ariis escribió:

...

On Sun, Apr 09, 2017 at 03:27:02PM -0500, amindfv@gmail.com wrote: Genuinely curious: can people point to specific examples in their (or others') code where the ((,) a) instance for Foldable is really helpful and difficult to replace?

I asked in the other thread, these are some of the answers I got:

Oliver Charles:

...

Personally, I think it would be a shame to lose foldMap on EIther. I frequently foldMap over Maybe values (where mempty is suitable in case of "failure"), and I can certainly see myself doing the same thing with Either.

Oleg Grenrus:

...

Anecdotally, today I wrote `foldMap toList`, to use as `Maybe (NonEmpty a) -> [a]`. Also I rely heavily in lens-based code on the `folded :: Fold (Maybe a) a`.

There haven't been replies on specific usage of functions length/sum/ maximum/etc.

I can't recall where, but someone else was making a point that a {-# Poison something #-} pragma would fracture the ecosystem. I don't think this holds much weight though, as library authors would most likely toggle the flag in development (to avoid calling length Either, etc.) and toggle it back on release.

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

Tony Morris writes:

A contrary, consistent position would mean there is a belief in all of the following:

* the length of any value of the type ((,) a) is not 1 * 0 is not an integer

You say this, but I’m wondering why. (-1) is also an integer, so can you give me an example for the (-1) case? — Jón

Two bits from the peanut gallery: We have an open world of universal instances. The question is not whether it's convenient to have these instances. It's whether there's any likelihood of someone deciding to define them elsewhere if they're not in base. Because then they exist anyway, and without nearly as much discussion and refinement. Yes, it's an unfortunate situation. Yes, "length" is a bad name. But the realities of the Haskell ecosystem dictate that when a single lawful instance of a base typeclass exists for a base data type, implementing it is pretty much mandatory. On Thu, Mar 30, 2017 at 2:36 PM, Bryan Richter wrote:

On Thu, Mar 30, 2017 at 11:18:10PM +0200, Henning Thielemann wrote:

...

On Thu, 30 Mar 2017, Bryan Richter wrote:

...

My intuition, based on observed usage in Haskell and elsewhere, is that tuples are used as anonymous product types. Thus, I am interested in the rationale for making them Functors because I feel it has denied me a common, valuable tool. I no longer feel that I should use pairs as product types. By making "(,) a" a Functor, it is no longer an anonymous product type —— it is an anonymous Reader. Are anonymous Readers really all that much more valuable than anonymous product types? I cannot conceive it. I must be missing something.

Pairs as functors are Writers. The function type got a Functor instance that corresponds to Readers.

Oops, laziness of the bad sort on my own part. :)

...

I think the only reason is that some programmers got "laziness" wrong and try to use primitive types for everything instead of using (and importing) dedicated types.

Well, is there anything to be done for it at this point? Is there even any consensus that this was, in retrospect, a poor choice?

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

But length is not a bad name. The length of ((,) a) is exactly one. It's because people keep calling this "the tuple instance", unaware that it is not the tuple instance. It is a conflation in vocabulary, leading to a misunderstanding of concepts and subsequent practical application. Jakub Daniel is exactly right, "It is categorically valid to view (a,-) as a functor. It is no different from 0 being an integer" Is 0 an integer? Is ((,) a) a functor? Is the length of ((,) a) equal to one? Whichever universe you choose to live in, these questions all have the same answer. I would respect the contrary position more if it was also argued that 0 is not an integer. On 31/03/17 07:53, Theodore Lief Gannon wrote:

Two bits from the peanut gallery:

We have an open world of universal instances. The question is not whether it's convenient to have these instances. It's whether there's any likelihood of someone deciding to define them elsewhere if they're not in base. Because then they exist anyway, and without nearly as much discussion and refinement.

Yes, it's an unfortunate situation. Yes, "length" is a bad name. But the realities of the Haskell ecosystem dictate that when a single lawful instance of a base typeclass exists for a base data type, implementing it is pretty much mandatory.

On Thu, Mar 30, 2017 at 2:36 PM, Bryan Richter mailto:b@chreekat.net> wrote:

On Thu, Mar 30, 2017 at 11:18:10PM +0200, Henning Thielemann wrote: > > On Thu, 30 Mar 2017, Bryan Richter wrote: > > >My intuition, based on observed usage in Haskell and elsewhere, is > >that tuples are used as anonymous product types. Thus, I am > >interested in the rationale for making them Functors because I feel > >it has denied me a common, valuable tool. I no longer feel that I > >should use pairs as product types. By making "(,) a" a Functor, it is > >no longer an anonymous product type —— it is an anonymous Reader. Are > >anonymous Readers really all that much more valuable than anonymous > >product types? I cannot conceive it. I must be missing something. > > Pairs as functors are Writers. The function type got a Functor > instance that corresponds to Readers.

Oops, laziness of the bad sort on my own part. :)

> I think the only reason is that some programmers got "laziness" wrong > and try to use primitive types for everything instead of using (and > importing) dedicated types.

Well, is there anything to be done for it at this point? Is there even any consensus that this was, in retrospect, a poor choice?

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org 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

Oops, same correction, Writer rather than Reader. A reflection of how little I think of them in terms of those semantics, I suppose. On Thu, Mar 30, 2017 at 2:56 PM, Nathan Bouscal wrote:

Well, is there anything to be done for it at this point? Is there even

...

any consensus that this was, in retrospect, a poor choice?

No, there isn't a consensus in either direction. As I understand it, the basic argument for pairs being functors is that there is a single possible way of making them functors, and that that instance *is* useful sometimes, so someone is going to define it anyway. One of the more convincing (to me) ways it (and other similar instances) is useful is as a building block for other types; Free and Cofree were mentioned last time this was discussed. The argument isn't so much about any specific instance being valuable, but rather about the health of the ecosystem of algebraic structures. Having arbitrary gaps in instance coverage because some people don't like those specific instances really doesn't seem reasonable.

I also don't agree with your description of it as an "anonymous Reader". The Functor instance is the only possible Functor instance for the type; "Reader" is an additional semantic description of one way of thinking about that instance.

On Fri, 31 Mar 2017, Herbert Valerio Riedel wrote:

On Thu, Mar 30, 2017 at 10:47 PM Bryan Richter wrote: I just don't know why pairs ever got to Functor. I fear this was an ancient decision... no?

If you're curious, this happened over 10 years ago:

http://git.haskell.org/ghc.git/commitdiff/209bf03ac7949c9bcf677561a2b1360b15...

Interesting. The Functor instance for pairs was added together with the Functor instance for functions. But the Monad instance for pairs came later, right?

Henning Thielemann writes:

On Thu, 23 Mar 2017, Fumiaki Kinoshita wrote:

...

It's surprising that they are missing (forgive me, I'm not here to make people grumpy).

I am not surprised because it was discussed at length a year before. I still think all these instances on pairs, triples and other tuples are more dangerous than helpful. It is so easy and much more expressive to define custom data types for your particular application. Actually, I am still actively using only GHC up to GHC-7.8.4, because starting with GHC-7.10.3 the slogan "if it can be compiled, it is certainly correct" cannot be reasonably claimed anymore (length(a,b)==1, maximum(2,1)==1 etc. are just not sane).

I wholeheartedly agree. -1 from me on all such proposals. I’m greatly dismayed at the rate at which arguments for convenience are winning over arguments for correctness. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk