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

Tony Morris tonymorris at gmail.com
Sat Apr 1 01:27:15 UTC 2017


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
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170401/1a3909bc/attachment.sig>


More information about the Libraries mailing list