<div dir="ltr">My answer this is: because Foldable instances on tuples make Haskell programming more dangerous.<div><br></div><div>With all instances, there is some risk of accidental unification with broken programs.  But in general, we are saved by one of two things: either the types are special-purpose enough that they are unlikely to occur by accident, or unification just propagates the incorrect type and the compiler merely puts the error message is in the wrong place.</div><div><br></div><div>With length and tuples, though, we're talking about a type that's used casually in many situations; and the accidental unification does not propagate the type at all.  Instead, it just generates incorrect code.  That's a bit scary!</div><div><br></div><div>It's unfortunate that discussions of this tend to get muddied by the possibility of length having a different meaning on tuples.  Really, IMHO, that's not even related to the problem.  The problem is that accidental unification is more risky here than anywhere other commonly used bit of Haskell that I can find. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 4, 2017 at 1:32 PM, MarLinn <span dir="ltr"><<a href="mailto:monkleyon@gmail.com" target="_blank">monkleyon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span class="">
    <p><br>
    </p>
    <blockquote type="cite">
      <pre>This to me is the center of the conversation: we're choosing whether we need the instances badly enough that we tolerate some, ahem, bad behavior.
</pre>
    </blockquote>
    <br>
    </span><p>I dispute that. To me, the center of the disagreement is between
      two different kinds of consistency: On the one hand, there's the
      consistency with a view of the world that treats One as a special
      number different from all other numbers. This view is based on the
      real world where singularities seem rampant. On the other side is
      consistency with a math-y view of the world that wants to unify as
      much as possible so we can reduce the number of models, thus,
      work.</p>
    <p>But if you want to treat the cardinality of one specially, do you
      want to drop Const and Identity, too? Const is closer to tuples
      than lists are, so why not cut them out as well? But then we had
      examples in just this conversation where Const and Identity where
      really useful. What argument is left to remove instances for
      tuples? If you can get over the 5-second weirdness of Const, why
      not tuples?<br>
    </p>
    At the end I claim there is no bad behavior. I do give you that
    there is <i>missing</i> behavior because the choice to have only
    that one instance per tuple size is a bit arbitrary and misleading.
    And that is hard to change for now. But do you really want to remove
    those few instances we do have just because we're not ready to
    include the others yet?<span class="HOEnZb"><font color="#888888"><br>
    <br>
    MarLinn<br>
  </font></span></div>

<br>______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div><br></div>