Generalizing map?

[Andrew Gibiansky]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150313/92260537/attachment.html>