Generalizing map?

[Michael Sloan]

Agreed, -1 from me. Painting the bike shed isn't a very good use of
everyone's brainpower, and doing so in an incremental fashion will
just drag out the pain of Prelude / base redesign.  Lets either rip
off the band aid in one go, or settle with modern Haskell eschewing
much of the Prelude.

Personally, things like this and BBP make me wish there wasn't a
Prelude in the first place.  At least it's helpful for improving
Haskell's scores in code golf :)

-Michael

On Fri, Mar 13, 2015 at 10:29 AM, 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
>