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

[Tony Morris]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170401/98320969/attachment.html>
-------------- 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/98320969/attachment.sig>