<div dir="ltr">I'm a strong +1 on this (and on Edward's addendum to it), and I object to the characterization of this change as having only trivial benefits. Simplicity and correctness are never trivial. In my view, disagreement on <i>how</i> this change is made (migration strategy, etc.) is completely reasonable, but disagreement on <i>whether</i> to make it is not.<br><br>There have been a lot of objections based on the idea that learners will consult books that are out of date, but the number of learners affected by this is dwarfed by the number of learners who will use updated materials and be confused by this strange historical artifact. Permanently-enshrined historical artifacts accrete forever and cause linear confusion, whereas outdated materials are inevitably replaced such that the amount of confusion remains constant.<br><br>There was also an argument that Haskell has a “window of opportunity”, implying that breakages are more likely to cost us future valued community members than historical artifacts are. I couldn't disagree more. If it weren't for Haskell's past willingness to make changes when we learned better ways of doing things, I doubt I would presently be using the language. I would much rather add a marginal community member with a strong preference for cleanliness, simplicity, and correctness than one with a strong preference against making occasional small changes to their code.<div hspace="streak-pt-mark" style="max-height:1px"><img style="width:0px;max-height:0px;overflow:hidden" src="https://mailfoogae.appspot.com/t?sender=abmJvdXNjYWxAZ21haWwuY29t&type=zerocontent&guid=ed8baa41-f02e-45dd-9f8f-d6d37158f2c6"><font color="#ffffff" size="1">ᐧ</font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 5, 2015 at 6:28 PM, Dimitri DeFigueiredo <span dir="ltr"><<a href="mailto:defigueiredo@ucdavis.edu" target="_blank">defigueiredo@ucdavis.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    +1<br>
    <br>
    I think this idea is good and should not be taken lightly. I'm a
    newcomer to the community and currently hold a grand total of *zero*
    open source contributions. Obviously, I would like to change this
    soon, but I think it is very *unfair* and makes absolutely no sense
    to have the standard one person one vote rule for decisions
    involving the libraries.<br>
    <br>
    Let the code produced vote. Maybe weight them by downloads?<span class="HOEnZb"><font color="#888888"><br>
    <br>
    Dimitri</font></span><div><div class="h5"><br>
    <br>
    <br>
    <br>
    <div>On 10/5/15 9:12 AM, Johan Tibell wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      <div dir="ltr">Perhaps we should weigh the +1 and -1s in this
        thread with the number of lines of Haskell written by the voter?
        ;)</div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Mon, Oct 5, 2015 at 5:09 PM, Gershom
          B <span dir="ltr"><<a href="mailto:gershomb@gmail.com" target="_blank">gershomb@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On October 5, 2015 at 10:59:35 AM, Bryan
              O'Sullivan (<a href="mailto:bos@serpentine.com" target="_blank">bos@serpentine.com</a>)
              wrote:<br>
              > I would like to suggest that the bar for breaking all
              existing libraries, books, papers,<br>
              > and lecture notes should be very high; and that the
              benefit associated with such a breaking<br>
              > change should be correspondingly huge.<br>
              ><br>
              <br>
            </span>My understanding of the argument here, which seems to
            make sense to me, is that the AMP already introduced a
            significant breaking change with regards to monads. Books
            and lecture notes have already not caught up to this, by and
            large. Hence, by introducing a further change, which
            _completes_ the general AMP project, then by the time books
            and lecture notes are all updated, they will be able to tell
            a much nicer story than the current one?<br>
            <br>
            As for libraries, it has been pointed out, I believe, that
            without CPP one can write instances compatible with AMP, and
            also with AMP + MRP. One can also write code, sans CPP,
            compatible with pre- and post- AMP.<br>
            <br>
            So the reason for choosing to not do MRP simultaneous with
            AMP was precisely to allow a gradual migration path where,
            sans CPP, people could write code compatible with the last
            three versions of GHC, as the general criteria has been.<br>
            <br>
            So without arguing the necessity or not, I just want to
            weigh in with a technical opinion that if this goes through,
            my _estimation_ is that there will be a smooth and
            relatively painless migration period, the sky will not fall,
            good teaching material will remain good, those libraries
            that bitrot will tend to do so for a variety of reasons more
            significant than this, etc.<br>
            <br>
            It is totally reasonable to have a discussion on whether
            this change is worth it at all. But let’s not overestimate
            the cost of it just to further tip the scales :-)<br>
            <span><font color="#888888"><br>
                —gershom<br>
              </font></span>
            <div>
              <div>_______________________________________________<br>
                Libraries mailing list<br>
                <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
                <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><span class=""><pre>_______________________________________________
Haskell-Cafe mailing list
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
</pre>
    </span></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>