A single general modification function for Map and IntMap proposal

[John Lato]

As I mentioned, I agree that the current ordering is wrong.  But there are
also the adjust and update families of functions.  I think there's much
more precedent for the lambda -> key order than you imply.  But I suppose
since they're all to be deprecated (I think that's part of the proposal?)
we don't need to perpetuate their mistakes.

(FWIW insertWith is one of the functions I would rather change.  The
argument order always feels backwards to me.)




On Thu, Jun 20, 2013 at 9:40 AM, Gershom Bazerman <gershomb at gmail.com>wrote:

>  +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 at 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 at ucw.cz> wrote:
>>
>> > Hi all,
>> >
>> >> -----Original message-----
>> >> From: Nikita Volkov <nikita.y.volkov at 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 at haskell.org
>> > http://www.haskell.org/mailman/listinfo/libraries
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://www.haskell.org/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130620/91c05967/attachment.htm>