Generalizing map?

[Nathan Bouscal]

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 at 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 <jwlato at gmail.com> wrote:
>
>> -1.
>>
>> On 08:05, Sun, Mar 15, 2015 Jeremy <voldermort at hotmail.com> 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 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/20150315/3f7d4611/attachment-0001.html>