Well put Andew! Put me as a -1 as well. On Fri, Mar 13, 2015 at 6:29 PM, Andrew Gibiansky < andrew.gibiansky@gmail.com> wrote:
While I love the idea of gradually "cleaning up" the Prelude, I have a few problems with this proposal.
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.
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.
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.
So, fairly strong -1 from me on this specific proposal in its current form.
However, if we want to continue cleaning up Prelude in a more principled way, I would strongly support that. How about something like this?
1. Gather a group of people interested in designing a proposal to clean up the Haskell prelude -- NPP, the New Prelude Proposal. 2. Detail an exhaustive list of changes we *could* want to make to the current Prelude. 3. Decide which of these changes are feasible to make in the near future (next five years). 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. 5. Organize the implementation of tools and extensions necessary to minimize breakage, and slowly work towards fixing our Prelude.
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.
-- Andrew
On Fri, Mar 13, 2015 at 8:06 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:
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
I think the only technical objection is making sure that theres no performance regressions wrt applicable fusion opportunities.
Subject to that, hearty plus one to fmap reclaiming map :)
Although I would prefer the far more radical (and thus far more unlikely to ever happen) approach of actually renaming 'fmap' to 'map'.
I'd vote for that too.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries