Re: Generalizing map?

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