Adding (??) into Data.Functor

[Dimitri Sabadie]

I know the pure case, and it's not really what we expect I guess. For list,
pure embed the value in a list and do combinatorial computations between
the two lists, whereas map ($ a) just maps the value over the list (faster
I guess).

I'm okay about your two points : let's make it a verbal function, and use a
-> f (a -> b) -> f b as signature.

Now, mapf sounds a bit cryptic I guess. Something like applyOn, onTo, or
something like that would be clearer IMHO.


On Sun, Feb 16, 2014 at 9:48 PM, Nikita Volkov <nikita.y.volkov at gmail.com>wrote:

> By the way, your original example (`l ?? a`) can already be written as `l
> <*> pure a` using the Applicative. So a new operator wouldn't gain that
> much.
>
>
> 2014-02-17 0:42 GMT+04:00 Nikita Volkov <nikita.y.volkov at gmail.com>:
>
> I too find such a function useful and deserving a place in the "base",
>> however I don't think that it's a good idea to make it an operator,
>> especially such a misleading one. I bet that I'm hardly alone in perception
>> of question marks as of indicator of a questionable data (e.g., Maybe), but
>> in no way of lists or functions. Therefore I suggest to instead consider
>> some verbal name for it. E.g., "mapApp" or "mapf" (as an opposite to
>> "fmap").
>>
>> Also, since the variable input of this combinator seems to be on the
>> functor side I suggest to inverse the arguments order order, i.e.:
>>
>>     mapf :: a -> f (a -> b) -> f b
>>
>> This way it'll target composition. And since it's a combinator over
>> functions it's a pretty important thing. E.g.:
>>
>>     mapf 2 . map (*) $ [1..10]
>>
>> So, +1 for the combinator, -1 for the proposed name and arguments order .
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140216/8d6610d1/attachment-0001.html>