Generalizing map?

[Andrew Gibiansky]

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150315/2e1f8226/attachment.html>