<div dir="ltr">While I love the idea of gradually "cleaning up" the Prelude, I have a few problems with this proposal.<div><br></div><div>1. This will break documentation *everywhere*.  This will make the majority of beginner tutorials flag out *wrong*. This is already happening a bit with type signatures due to BBP, but my intuition tells me that `map` and `fmap` are even more commonly used in tutorials, and will break even more. </div><div><br></div><div>2. If we're willing to make changes to `map`, are there other things that we want to generalize or clean up? Rather than a dozen small email threads about "add this function" or "generalize this", perhaps we could instead take a good hard look at the Prelude, and decide on a long-scale migration plan. What do we want in the long run? How do we accomplish it with least breakage? What sort of tooling can we develop -- language extensions, Haskell preprocessors, etc -- that could make a migration to a cleaner prelude as easy as possible? Overall, I am a huge fan of striving towards a more beautiful Prelude, but I want it done in a principled way. I fear that if these sorts of threads are the way it happens, we will hear from a very select few among the Haskell community, and the spectacle of BBP may repeat itself. </div><div><br></div><div>3. This would break a lot of code, I think. My intuition tells me that using `map` instead of `fmap` is often used to specify types -- that is, many places will be ambiguous if we generalize map.</div><div><br></div><div>So, fairly strong -1 from me on this specific proposal in its current form.</div><div><br></div><div>However, if we want to continue cleaning up Prelude in a more principled way, I would strongly support that. How about something like this?</div><div><br></div><div>1. Gather a group of people interested in designing a proposal to clean up the Haskell prelude -- NPP, the New Prelude Proposal.</div><div>2. Detail an exhaustive list of changes we *could* want to make to the current Prelude.</div><div>3. Decide which of these changes are feasible to make in the near future (next five years).</div><div>4. Decide how we could make each of the changes, specifically figuring out how much code would break, how the change could be made to avoid breakage, and so on.</div><div>5. Organize the implementation of tools and extensions necessary to minimize breakage, and slowly work towards fixing our Prelude.</div><div><br></div><div>That said, perhaps we don't actually have that many changes that need to happen, and thus NPP is not relevant, but even in that case, I'd like to see a more formal proposal, with at least an analysis of how much code currently available on Hackage would break if we changed `map`s signature.</div><div><br></div><div>-- Andrew</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 13, 2015 at 8:06 AM, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Earlier versions of the haskell standard originally named fmap map.  It was only as of haskell 1.4 or so that what was then map got renamed to map</p>
<p dir="ltr">I think the only technical objection is making sure that theres no performance regressions wrt applicable fusion opportunities. </p>
<p dir="ltr">Subject to that, hearty plus one to fmap reclaiming map :)</p>
<div style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr">> <span style="font-size:12.8000001907349px">Although I would prefer the far more radical (and thus far more</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">unlikely to ever happen) approach of actually renaming 'fmap' to 'map'.</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I'd vote for that too.</span></div><div class="gmail_extra"><br></div></div>
<br></span><span class="">_______________________________________________<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" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></span></div>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>