Generalizing map? - Libraries - Haskell.org

newer
zipWithA, zipWithA_, mapAndUnzipA,...

Generalizing map?

older
Proposal: Add (<$>) to Prelude as...

Fumiaki Kinoshita

13 Mar 2015 13 Mar '15

5:32 a.m.

A dozen of functions like concat, foldr, mapM, have been generalized through BBP. Then, why do we leave `map` just for lists? Obviously `map` can be generalized, so map :: Functor f => (a -> b) -> f a -> f b map = fmap The current definition of `map` looks too special to be a special case of mapM (map f = runIdentity . mapM (Identity . f)).

Attachments:

attachment.html (text/html — 462 bytes)

Reply

Sign in to reply online Use email software

Show replies by date

Nikita Volkov

13 Mar 13 Mar

5:35 a.m.

I can't +1 this enough to express how much I desire that change! 2015-03-13 12:32 GMT+03:00 Fumiaki Kinoshita :

A dozen of functions like concat, foldr, mapM, have been generalized through BBP.

Then, why do we leave `map` just for lists? Obviously `map` can be generalized, so

map :: Functor f => (a -> b) -> f a -> f b map = fmap

The current definition of `map` looks too special to be a special case of mapM (map f = runIdentity . mapM (Identity . f)).

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Reply

Sign in to reply online Use email software

Erik Hesselink

5:40 a.m.

Why is this change so important when fmap is already in the prelude? Erik On Fri, Mar 13, 2015 at 10:35 AM, Nikita Volkov wrote:

I can't +1 this enough to express how much I desire that change!

2015-03-13 12:32 GMT+03:00 Fumiaki Kinoshita :

...
A dozen of functions like concat, foldr, mapM, have been generalized through BBP.

Then, why do we leave `map` just for lists? Obviously `map` can be generalized, so

map :: Functor f => (a -> b) -> f a -> f b map = fmap

The current definition of `map` looks too special to be a special case of mapM (map f = runIdentity . mapM (Identity . f)).

_______________________________________________ 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

Reply

Sign in to reply online Use email software

Nikita Volkov

6 a.m.

I don't know any function that is used more frequently. The only argument for the existence of the specialised `map` that I've heard is that it's supposed to make the type signatures simpler for the newbies. I find this argument outright wrong. The simplicity of the Prelude ship has sailed long ago. With the already scheduled changes it's gonna sail twice as far. Also I find the sole premise of trying to look simple to the newbies a waste of effort and consistency of API. 2015-03-13 12:40 GMT+03:00 Erik Hesselink :

Why is this change so important when fmap is already in the prelude?

Erik

On Fri, Mar 13, 2015 at 10:35 AM, Nikita Volkov wrote:

...
I can't +1 this enough to express how much I desire that change!

2015-03-13 12:32 GMT+03:00 Fumiaki Kinoshita :

...
A dozen of functions like concat, foldr, mapM, have been generalized through BBP.

Then, why do we leave `map` just for lists? Obviously `map` can be generalized, so

map :: Functor f => (a -> b) -> f a -> f b map = fmap

The current definition of `map` looks too special to be a special case

of

...
mapM (map f = runIdentity . mapM (Identity . f)).

_______________________________________________ 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

Reply

Sign in to reply online Use email software

Christopher Allen

6:07 a.m.

Strong, but self-consciously hopeless, (+1) from me. Existence of the redundant `map` has confused many new people I've worked with. It was based on an early understanding of what was confusing or not to new people. `fmap` can be specialized by an explicit type - you can elide the existence of Functor from learning materials until it's appropriate without having API redundancy. Haskell 1.4 had it right to begin with. The real argument against this change would the ambiguous type errors that would result. Compile-time type error but easily fixed with an explicit type annotation. I'm not an imaginative person, but I can't think of any other problems at this time. On Fri, Mar 13, 2015 at 4:35 AM, Nikita Volkov wrote:

I can't +1 this enough to express how much I desire that change!

2015-03-13 12:32 GMT+03:00 Fumiaki Kinoshita :

...
A dozen of functions like concat, foldr, mapM, have been generalized through BBP.

Then, why do we leave `map` just for lists? Obviously `map` can be generalized, so

map :: Functor f => (a -> b) -> f a -> f b map = fmap

The current definition of `map` looks too special to be a special case of mapM (map f = runIdentity . mapM (Identity . f)).

_______________________________________________ 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

Reply

Sign in to reply online Use email software

Alexander Berntsen

6:52 a.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 +1. Although I would prefer the far more radical (and thus far more unlikely to ever happen) approach of actually renaming 'fmap' to 'map'. - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlUCwVIACgkQRtClrXBQc7XSyAD/S9z64F6v1HMdp7WXYH59dKmj +xVnZkoYBe58h2u7ok0A/3c5uAlZTigDLWKaeW9uMzLVLRn6SXf4XrlIQhv11Fz9 =NPlO -----END PGP SIGNATURE-----

Reply

Sign in to reply online Use email software

Nikita Volkov

7:41 a.m.

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.

Reply

Sign in to reply online Use email software

Carter Schonwald

11:06 a.m.

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

Reply

Sign in to reply online Use email software

Andrew Gibiansky

1:29 p.m.

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

Reply

Sign in to reply online Use email software

Adam Bergmark

1:33 p.m.

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

Reply

Sign in to reply online Use email software

Oliver Charles

4:13 p.m.

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 wrote:

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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Reply

Sign in to reply online Use email software

Michael Sloan

6:40 p.m.

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 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 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

Reply

Sign in to reply online Use email software

Henning Thielemann

7:03 p.m.

On Fri, 13 Mar 2015, Michael Sloan wrote:

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.

I would prefer to stop patching Prelude and instead promote: https://ghc.haskell.org/trac/ghc/wiki/SplitBase

Reply

Sign in to reply online Use email software

Ivan Lazar Miljenovic

7:10 p.m.

On 14 March 2015 at 10:03, Henning Thielemann wrote:

On Fri, 13 Mar 2015, Michael Sloan wrote:

...
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.

I would prefer to stop patching Prelude and instead promote: https://ghc.haskell.org/trac/ghc/wiki/SplitBase

+1 to this (And -1 to the actual proposal for all the reasons stated.) -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

Reply

Sign in to reply online Use email software

Jeremy

15 Mar 15 Mar

11:05 a.m.

+1 for generalising map. People who think that it will break lots of code should compile some popular packages and see for themselves. As for a better/no prelude, this has been talked about for years, but a wholesale replacement of the prelude hasn't happened yet and probably won't. Waiting for something that won't happen is no reason to block gradual improvement. -- View this message in context: http://haskell.1045720.n5.nabble.com/Generalizing-map-tp5766936p5767023.html Sent from the Haskell - Libraries mailing list archive at Nabble.com.

Reply

Sign in to reply online Use email software

John Lato

11:24 a.m.

-1. On 08:05, Sun, Mar 15, 2015 Jeremy wrote:

+1 for generalising map.

People who think that it will break lots of code should compile some popular packages and see for themselves. As for a better/no prelude, this has been talked about for years, but a wholesale replacement of the prelude hasn't happened yet and probably won't. Waiting for something that won't happen is no reason to block gradual improvement.

-- View this message in context: http://haskell.1045720.n5. nabble.com/Generalizing-map-tp5766936p5767023.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Reply

Sign in to reply online Use email software

Andrew Gibiansky

1:56 p.m.

As for a better/no prelude, this has been talked about for years, but a wholesale replacement of the prelude hasn't happened yet and probably won't. Waiting for something that won't happen is no reason to block gradual improvement.

Note that I am not arguing for waiting for a wholesale replacement! I am all in favor of gradual improvement -- in fact, I think that's the only way to go about improving the prelude. But that gradual improvement can be *targeted*. We can have a plan, instead of having dozens of tiny proposals about adding this function or generalizing another function or deprecating a function. That is what I was arguing for. -- Andrew On Sun, Mar 15, 2015 at 8:24 AM, John Lato wrote:

-1.

On 08:05, Sun, Mar 15, 2015 Jeremy wrote:

...
+1 for generalising map.

People who think that it will break lots of code should compile some popular packages and see for themselves. As for a better/no prelude, this has been talked about for years, but a wholesale replacement of the prelude hasn't happened yet and probably won't. Waiting for something that won't happen is no reason to block gradual improvement.

-- View this message in context: http://haskell.1045720.n5. nabble.com/Generalizing-map-tp5766936p5767023.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ 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

Reply

Sign in to reply online Use email software

Nathan Bouscal

2:25 p.m.

I strongly agree with Andrew's suggestion of figuring out exactly what we want the Prelude to be and then moving toward that goal. A principled, intentional approach to this would be really wonderful. That said, I don't agree with holding off on concrete small changes in the meantime, because my pessimistic side doesn't actually expect that principled approach to ever come to fruition. Rejecting a proposal like this current one in favor of a more thorough, principled approach seems to me like allowing the perfect to be the enemy of the good. I would rather have a team working on the better solution, but allow the merely good solutions to continue happening in parallel. I'm skeptical about code breakage, and think we should simply test it and find out.

From my (very limited) experience teaching beginners, I expect this change to improve things, not make them worse. I'm glad to see that Chris's much greater experience in this area seems to corroborate this.

That leaves me at +1 on this for now, conditional on testing to be sure that it wouldn't cause significant code breakage or problems with fusion. (I'm also a quixotic +1 on going all the way and renaming fmap to map, but can't imagine that actually happening any time soon.) On Sun, Mar 15, 2015 at 10:56 AM, Andrew Gibiansky < andrew.gibiansky@gmail.com> wrote:

...
As for a better/no prelude, this has been talked about for years, but a wholesale replacement of the prelude hasn't happened yet and probably won't. Waiting for something that won't happen is no reason to block gradual improvement.

Note that I am not arguing for waiting for a wholesale replacement! I am all in favor of gradual improvement -- in fact, I think that's the only way to go about improving the prelude.

But that gradual improvement can be *targeted*. We can have a plan, instead of having dozens of tiny proposals about adding this function or generalizing another function or deprecating a function. That is what I was arguing for.

-- Andrew

On Sun, Mar 15, 2015 at 8:24 AM, John Lato wrote:

...
-1.

On 08:05, Sun, Mar 15, 2015 Jeremy wrote:

...
+1 for generalising map.

People who think that it will break lots of code should compile some popular packages and see for themselves. As for a better/no prelude, this has been talked about for years, but a wholesale replacement of the prelude hasn't happened yet and probably won't. Waiting for something that won't happen is no reason to block gradual improvement.

-- View this message in context: http://haskell.1045720.n5. nabble.com/Generalizing-map-tp5766936p5767023.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ 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

Reply

Sign in to reply online Use email software

David Feuer

13 Mar 13 Mar

9:44 a.m.

We need to be very careful to make sure we don't break list fusion. map is one of relatively few functions that are both "good consumers" and "good producers". This makes it especially sensitive to anything affecting simplification. Making map be fmap means that it will not be recognized as the thing that should fuse until later in the process, and we want to be sure that doesn't kill all the benchmarks. -- David Feuer If you like my advice, please hire me. On Fri, Mar 13, 2015 at 5:32 AM, Fumiaki Kinoshita wrote:

A dozen of functions like concat, foldr, mapM, have been generalized through BBP.

Then, why do we leave `map` just for lists? Obviously `map` can be generalized, so

map :: Functor f => (a -> b) -> f a -> f b map = fmap

The current definition of `map` looks too special to be a special case of mapM (map f = runIdentity . mapM (Identity . f)).

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Reply

Sign in to reply online Use email software

3719

Age (days ago)

3721

Last active (days ago)

Download

18 comments

16 participants

tags

participants (16)

Adam Bergmark
Alexander Berntsen
Andrew Gibiansky
Carter Schonwald
Christopher Allen
David Feuer
Erik Hesselink
Fumiaki Kinoshita
Henning Thielemann
Ivan Lazar Miljenovic
Jeremy
John Lato
Michael Sloan
Nathan Bouscal
Nikita Volkov
Oliver Charles