<p dir="ltr">I think code-based weighting should not be considered at all. There's a non-trivial amount of proprietary code that wouldn't be counted, and likely can't be accounted for accurately. I have some unknown amount of code at my previous employer (which does include Monad instances) that now has to be maintained by others. I may have said +1 (and I'm reconsidering), but the current maintainers probably don't want the extra make-work this involves.</p>
<p dir="ltr">There's an argument that this proposal involves very little up-front breakage. This is true but disingenuous, because the breakage will still happen in the future unless changes are made and committed. The entire maintenance load should be considered, not just the immediate load. </p>
<p dir="ltr">Bryan, nothing I've seen since I started using Haskell makes me think that the libraries committee or ghc devs value back compatibility much at all. My favorite example is RecursiveDo, which was deprecated in favor of DoRec, only for that to be reversed in the next ghc release. Of course that was more irritating than breaking, but it's indicative of the general value placed on maintenance programming.</p>
<br><div class="gmail_quote"><div dir="ltr">On 12:28, Mon, Oct 5, 2015 Dimitri DeFigueiredo <<a href="mailto:defigueiredo@ucdavis.edu">defigueiredo@ucdavis.edu</a>> wrote:<br></div><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?<br>
<br>
Dimitri</div><div bgcolor="#FFFFFF" text="#000000"><br>
<br>
<br>
<br>
<div>On 10/5/15 9:12 AM, Johan Tibell wrote:<br>
</div>
</div><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite">
<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>
</blockquote></div><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite"><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>
</blockquote>
<br>
</div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">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>
</blockquote></div>