<div dir="ltr">Again, the intention was to <b>have a discussion</b> about doing so early in 7.12.<div><br></div><div>* Keeping foldr, etc. in Data.List in 7.10 monomorphic in the face of a generalized Prelude would break an enormous amount of code. It would force users who currently do not use qualified imports to do so and increase conflicts over all. As it is, even Neil and Lennart on the agreed on a call the other day that the Foldable/Traversable changes break almost no code.</div><div><div><br></div><div>* Keeping those combinators in there and generalized indefinitely breaks basically no code, but leads to flare ups like the current one where folks look at the illogical-seeming intermediate state and get upset.</div></div><div><br></div><div>* Removing those generalized, redundant combinators after a deprecation cycle gives a path by which in the annoyance at the state of affairs in the second option can fade, admittedly at the expense that there is no place for the monomorphic versions to live. This gives two years for folks to adapt a <b>much</b> smaller set of code, replete with smoothly handleable warnings.</div><div><br></div><div><div>* By way of contrast, just reverting them to be monomorphic in 7.12 or 7.14 would break just as much code a year or two later. It is an option folks could advocate for, but it is an option that has no smooth upgrade path from the status quo, making it a very awkward option to enact at best. It has the benefit that the monomorphic versions of those combinators would have a place to live, but getting there requires much higher transitional pain in the absence of language extensions to make it possible. Now, one could envision a language pragma or the like that would enable us to go down this path. e.g. Lennart's WEAK pragma or by crafting a technical solution whereby you can export with restricted signatures. In the short term we took such technical fixes off the table as far too messy to address the issue, and when such proposals have come up in the past they've been fairly controversial.</div></div><div><br></div><div>So of those four options, I'd prefer to go down the third path in the absence of folks agreeing on extending the language in ways to make the fourth option viable, but there is definitely room for debate.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 4, 2015 at 12:42 PM, Johan Tibell <span dir="ltr"><<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Feb 4, 2015 at 9:22 AM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@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 dir="ltr">The original intent had been to have a discussion about deprecating the generalized combinators in Data.List in 7.12 and removing them in 7.14 once we had the ability to deprecate a re-export.<div><br></div><div>This path gives a 2 year window for the much smaller pool of users who import Data.List qualified and also use List.foldr to drop "List." from their code, and a way to gracefully provide warnings, without immediately breaking the larger pool of users who import Data.List unqualified and just reach for members that aren't in the Prelude and rely on the lack of conflicts today.</div></div></blockquote><div><br></div></span><div>Wait, are we removing foldr from Data.List entirely?</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I don't see a path that results in monomorphic members of Data.List for those particular combinators that doesn't require a sharp shock in which a bunch of code breaks for a large pool of users without us being able to warn them first.</div><div><br></div><div>-Edward</div><span><font color="#888888"><div><br></div><div><br></div><div><br></div><div><div>-Edward</div></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 4, 2015 at 12:05 PM, Johan Tibell <span dir="ltr"><<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@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 dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Feb 4, 2015 at 9:01 AM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@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 dir="ltr">The current step was to generalize them so that code that imported Data.List so that they don't conflict with the Prelude versions.<div><br></div><div>The intent was that once we gained the ability to deprecate re-exports that we'd remove them entirely. We now have a patch that enables us to do such things.</div><div><br></div><div>It turns out that if you look at hackage, for the most part folks are actually importing Data.List unqualified to bring into scope <font face="monospace, monospace">foldl'</font> or <font face="monospace, monospace">sort. </font><font face="arial, helvetica, sans-serif">Almost nobody invokes </font><font face="monospace, monospace">foldr</font><font face="arial, helvetica, sans-serif"> from it</font>.</div><div><br></div><div>The "generalization and subsequent re-export deprecation" path breaks less code than the "leaving them monomorphic and breaking everyone who uses Data.List unqualified" path, even if it leads to an intermediate state that is a bit awkward, and doesn't lead easily to a final state where monomorphic versions of those combinators are available.</div></div></blockquote><div><br></div></span><div>I didn't quite follow this. Does this mean that the Data.List functions will be generalized for now but eventually monomorphized again?</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><font color="#888888"><div><br></div><div>-Edward</div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, Feb 4, 2015 at 11:13 AM, Christopher Done <span dir="ltr"><<a href="mailto:chrisdone@gmail.com" target="_blank">chrisdone@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>> Looking at the generalizations in Data.List I find them pretty odd now when<br>
> I think about it. I'd expect Data.List functions to be monomorphic to<br>
> lists, just like I expect functions in Data.Map to be monomorphic to maps.<br>
> Now there might be generalized versions of these functions in e.g. the<br>
> Prelude, but generalizing Data.List means that I don't even have the<br>
> monomorphic versions available if I want to resolve ambiguity by using<br>
> them*.<br>
<br>
Sums up my feelings exactly. Data.Map, Data.List, etc. should be<br>
monomorphic. Adding generalized functions in Data.List is a little<br>
baffling.<br>
</div></div><span><div><div>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></span></blockquote></div><br></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>