Generalizing map?

[Adam Bergmark]

Well put Andew! Put me as a -1 as well.


On Fri, Mar 13, 2015 at 6:29 PM, Andrew Gibiansky <
andrew.gibiansky at 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 at 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150313/94f0c284/attachment-0001.html>