<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>A contrary, consistent position would mean there is a belief in
all of the following:</p>
<p>* the length of any value of the type ((,) a) is not 1<br>
* 0 is not an integer</p>
<p>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.</p>
<p>Restated:</p>
<p>* the length semantics of ((,) a) are total nonsense.<br>
* that 0 is an integer, is total nonsense.<br>
</p>
<p>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.<br>
</p>
<br>
<div class="moz-cite-prefix">On 31/03/17 19:23, Sven Panne wrote:<br>
</div>
<blockquote
cite="mid:CANBN=mtm2LP95CPTvc4EmDBCQUFUV14SUvO_Xja8en4o_pPx3w@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">2017-03-30 23:49 GMT+02:00 Henning
Thielemann <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:lemming@henning-thielemann.de"
target="_blank">lemming@henning-thielemann.de</a>></span>:<br>
<blockquote class="gmail_quote">The community was and is
pretty divided, I think. My suggested compromise is to get
compiler warnings if you use certain instances (by
accident).</blockquote>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div> * 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.</div>
<div><br>
</div>
<div> * 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.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div> a) Actually nuke the pair instances, accepting the
resulting damage and "holes".</div>
<div><br>
</div>
<div> 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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Next battle: What will be the default for the
flag/pragma? >:-)</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Libraries mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre>
</blockquote>
<br>
</body>
</html>