Generalizing map?

[Oliver Charles]

I imagine there's a lot of code that's relying on the old map for
inference, and changing this would make types ambiguous. That is a huge
penalty to pay for what is mostly a nice-to-have.

If people care this strongly about being able to use `map` in their own
code, then I think the only solution is to use a custom Prelude.

-1.

On Fri, Mar 13, 2015 at 5:33 PM, Adam Bergmark <adam at bergmark.nl> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/0f38435b/attachment.html>