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

Sven Panne svenpanne at gmail.com
Fri Mar 31 09:23:16 UTC 2017


2017-03-30 23:49 GMT+02:00 Henning Thielemann <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? >:-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170331/6589ca5c/attachment.html>


More information about the Libraries mailing list