Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

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

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Jon Fairbairn
Henning Thielemann <[hidden email]> 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                                 [hidden email]

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

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Sven Panne-2
In reply to this post by Henning Thielemann
2017-03-30 23:49 GMT+02:00 Henning Thielemann <[hidden email]>:
The community was and is pretty divided, I think. My suggested compromise is to get compiler warnings if you use certain instances (by accident).

I fully agree with Henning here, and I think we will never ever reach a consensus about these instances. This is caused by the fact that there are 2 contradicting goals here, and which one is more important is a totally personal opinion, not something which can be proved or shown otherwise:

   * Type safety, a.k.a. "if it compiles, it works": We definitely lose on this side with the given instances, and we lose even more when there are more instances.

   * Consistency: If there is a unique way to define an instance, let's do it, and do it for *all* such types. Just like type safety, this is a valuable goal, and one which is reached by Haskell to very large amount.

Personally, I would very much prefer nuking the Functor/... instances for pairs, the resulting length/maximum/... semantics are total nonsense, even if they are consistent. Let's not forget the "principle of least surprise", a very worthy goal, which is heavily damaged by these instances. But the pair instances are already there, and removing them would damage the Haskell ecosystem quite a bit. So what can we do?

   a) Actually nuke the pair instances, accepting the resulting damage and "holes".

   b) Keep the pair instances. But then we should really add the remaining tuple instances, too (consistency!), *and* we should add a compiler flag/pragma for people wanting to avoid them.

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.

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

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

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Henning Thielemann

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

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Herbert Valerio Riedel-3
In reply to this post by Bryan Richter-2
On Thu, Mar 30, 2017 at 10:47 PM Bryan Richter <[hidden email]> 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:


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

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Henning Thielemann

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

> On Thu, Mar 30, 2017 at 10:47 PM Bryan Richter <[hidden email]> 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/209bf03ac7949c9bcf677561a2b1360b158e3b22

Interesting. The Functor instance for pairs was added together with the
Functor instance for functions. But the Monad instance for pairs came
later, right?
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Tony Morris-4
In reply to this post by Sven Panne-2

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

I have never seen this position, which would be a consistent, third position. These leaves two remaining positions; one of consistency and one of inconsistency.

Restated:

* the length semantics of ((,) a) are total nonsense.
* that 0 is an integer, is total nonsense.

I could totally respect this position. It would make a lot more sense. It would be consistent. It would be defendable. I would admire it.


On 31/03/17 19:23, Sven Panne wrote:
2017-03-30 23:49 GMT+02:00 Henning Thielemann <[hidden email]>:
The community was and is pretty divided, I think. My suggested compromise is to get compiler warnings if you use certain instances (by accident).

I fully agree with Henning here, and I think we will never ever reach a consensus about these instances. This is caused by the fact that there are 2 contradicting goals here, and which one is more important is a totally personal opinion, not something which can be proved or shown otherwise:

   * Type safety, a.k.a. "if it compiles, it works": We definitely lose on this side with the given instances, and we lose even more when there are more instances.

   * Consistency: If there is a unique way to define an instance, let's do it, and do it for *all* such types. Just like type safety, this is a valuable goal, and one which is reached by Haskell to very large amount.

Personally, I would very much prefer nuking the Functor/... instances for pairs, the resulting length/maximum/... semantics are total nonsense, even if they are consistent. Let's not forget the "principle of least surprise", a very worthy goal, which is heavily damaged by these instances. But the pair instances are already there, and removing them would damage the Haskell ecosystem quite a bit. So what can we do?

   a) Actually nuke the pair instances, accepting the resulting damage and "holes".

   b) Keep the pair instances. But then we should really add the remaining tuple instances, too (consistency!), *and* we should add a compiler flag/pragma for people wanting to avoid them.

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.

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


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


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

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Edward Kmett-2
In reply to this post by Henning Thielemann
The Monad instance for pairs came later mostly because there was a big dependency inversion / orphan problem with getting at Monoid for it, but yes.

-Edward

On Fri, Mar 31, 2017 at 1:24 PM, Henning Thielemann <[hidden email]> wrote:

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

On Thu, Mar 30, 2017 at 10:47 PM Bryan Richter <[hidden email]> 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/209bf03ac7949c9bcf677561a2b1360b158e3b22

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

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


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

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

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

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Tony Morris-4
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:

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


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

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

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


--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

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

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Tony Morris-4


On 01/04/17 17:24, Andreas Abel wrote:
> > 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?!

No. It is perfectly reasonable. Go and "ask the mathematics department"
or whatever criteria it will take for (the collective) you to understand
that.

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

We already agree on the result. Thanks again for pointing out, that I am
pointing to the mistake that is repeatedly made. I will just keep
pointing to it. Just keep that mistake out of my code, thanks.


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

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Henrik Nilsson-2
In reply to this post by Andreas Abel-2
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.

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

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Ivan Lazar Miljenovic
On 1 April 2017 at 19:42, Henrik Nilsson
<[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



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

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Andreas Abel-2
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
> <[hidden email]> 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
>> [hidden email]
>> 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

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

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Dominic Steinitz-2
In reply to this post by Fumiaki Kinoshita
Since "God made the integers…” perhaps the question of whether 0 is an integer is best left to theologians.

On the other hand, in set theory a tuple is defined as a set containing two elements and in category theory, a product is a limit of a discrete category with two objects. Of course you can treat a tuple as a decorated container containing one element but I doubt many mathematicians think of them this way. Before anyone points out that I shouldn’t think of types as sets, the same applies to \omega-complete partial orders.

Perhaps I had better be explicit and say please no aka -1.

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


Dominic Steinitz
[hidden email]
http://idontgetoutmuch.wordpress.com

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

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Jakub Daniel
In reply to this post by Andreas Abel-2


> On 1 Apr 2017, at 13:00, Andreas Abel <[hidden email]> wrote:
>
> 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
>> <[hidden email]> 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
>>> [hidden email]
>>> 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
>
> [hidden email]
> http://www.cse.chalmers.se/~abela/
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Jakub Daniel
In reply to this post by Andreas Abel-2

> 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
>> <[hidden email]> 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
>>> [hidden email]
>>> 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
>
> [hidden email]
> http://www.cse.chalmers.se/~abela/
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Henning Thielemann

On Sat, 1 Apr 2017, Jakub Daniel wrote:

> 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 (-,-).

And for me the context (a,-) is artificial.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Henning Thielemann
In reply to this post by Andreas Abel-2

On Sat, 1 Apr 2017, Andreas Abel wrote:

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

I have to admit that I even accept this more than length on pairs. I used
to use Maybe for lists with length 0 or 1.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

Sven Panne-2
In reply to this post by Ivan Lazar Miljenovic
2017-04-01 12:32 GMT+02:00 Ivan Lazar Miljenovic <[hidden email]>:
[...] 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.

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