Generalizing map?

[Christopher Allen]

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 <nikita.y.volkov at gmail.com>
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 <fumiexcel at gmail.com>:
>
>> 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 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/20150313/54ea9bb4/attachment.html>