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@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@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 .