+1 for the key -> lambda form. Even disregarding lens, compositionality is extremely important. Not to mention which, the key -> lambda form feels much more natural even on its own. You provide an "index" and get back a function that lifts element modifications to map modifications.

The only lambda -> key functions I see in the current API are the insertWith family and "alter". I think the parameter order on "alter" is backwards as well (and maybe we can eliminate it in time now that we have alterF? I suspect the current version is fairly rarely used anyway). And insertWith is hardly analogous.

Meanwhile, if we look at "member", "lookup", "insert", etc, the key comes first, which is very useful.

In general, I expect the key -> lambda version will be much more commonly used, since it matches how one would tend to think of alterF (creating a map transformer, as opposed to applying a transformation, but not yet knowing where to do so).

--G

On 6/19/13 9:26 PM, John Lato wrote:
I think consistency with the rest of the Map API is more important than ease of use with lens/nested compositions.  I agree that the current arg ordering is often inconvenient, but having some functions ordered one way and others a different way seems a very poor decision.

John L.


On Wed, Jun 19, 2013 at 9:14 PM, Edward A Kmett <ekmett@gmail.com> wrote:
Flipping to lambda -> key means that you cannot compose these for nested lookups.

alterF in its current form is a valid lens.

A very common idiom from the lens community is to do lookups in nested maps with the equivalent of:

alterF key1 . traverse . alterF key2

There is a similar idiom for doing inserts into nested maps as well.

Flipping it means any composition of alterF incurs lots of flips.

-Edward

On Jun 19, 2013, at 8:27 AM, Milan Straka <fox@ucw.cz> wrote:

> Hi all,
>
>> -----Original message-----
>> From: Nikita Volkov <nikita.y.volkov@gmail.com>
>> Sent: 19 Jun 2013, 13:47
>>
>> Hello guys!
>>
>> A deadline of a discusssion on this has been reached. To review the discussion you can visit the archives. Following is a summarization.
>>
>> 1. Following is an implementation proposed by Schachaf Ben-Kiki, which in a combination with an `INLINABLE` pragma produces very impressive results by making even the primitive operations reimplemented in terms of it perform better:
>>
>> insert: ~ +5% increase using alterF
>> delete: ~ +10% increase using alterF
>
> I probably did not make myself clear enough -- the insert reimplemented
> with alterF runs 5% slower (the running time is increased by 5%) and
> similarly for delete.
>
>>   alterF :: (Ord k, Functor f) => k -> (Maybe a -> f (Maybe a)) -> Map k a -> f (Map k a)
>>   STRICT_1_OF_2(alterF)
>>   alterF k f = go
>>     where
>>       go Tip = maybe Tip (singleton k) <$> f Nothing
>>       go (Bin sx kx x l r) =
>>         case compare k kx of
>>           LT -> (\l' -> balance kx x l' r) <$> go l
>>           GT -> (\r' -> balance kx x l r') <$> go r
>>           EQ -> maybe (glue l r) (\x' -> Bin sx kx x' l r) <$> f (Just x)
>>
>> 2. `alterF` seems to be a mutually accepted title for the function
>>
>> 3. There was one downvote for implementing `alterF` with a changed order of parameters to "key -> lambda", as compared to "lambda -> key" of other modification functions in the library. Others seemed to be neutral about it. The implementation above is in that changed order. After some thinking my vote can be counted as a downvote too on that.
>
> Looking at alterF, I think we should be consistent with the rest of the
> API and use lambda -> key.
>
>
> Cheers,
> Milan
>
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries