Proposal reminder: Add functions to get consecutive elements to Data.List

[Edward Kmett]

I'm personally a weak -1 on adding a mapAdjacent combinator.

Ultimately

length "mapAdjacent" == length "ap zip tail"

and there are all the silly nearby functions that sound like they'd want
similar names that would use things like:

mapPairwise f (a:b:cs) = f a b:mapPairwise f cs

or

mapPairwise f (a:bcs@(b:cs)) = f a b:mapPairwise f bcs

leading to some confusion, and forcing you to read the docs to figure out
what the function does.

-Edward

On Thu, May 19, 2016 at 2:38 PM, David Feuer <david.feuer at gmail.com> wrote:

> I think I like mapPairwise. And I really will try to get a proper list
> fusion implementation for this if it goes in. The rewrite-back rules are
> always a bit of a pain.
> On May 19, 2016 2:34 PM, "Theodore Lief Gannon" <tanuki at gmail.com> wrote:
>
>> Whoops, responded privately (and also made a mistake I wanted to correct,
>> so I guess that works out). To the list this time:
>>
>> I don't like using the 'zip' terminology here; I feel like that should be
>> reserved for multiple distinct data sources.
>>
>> Why not 'map2'?
>>
>> On Thu, May 19, 2016 at 4:32 AM, Johan Holmquist <holmisen at gmail.com>
>> wrote:
>>
>>> Also these two were mentioned earlier (using zipConsecutivesWith):
>>>
>>>     -- fibonacci:
>>>     fibs = 1 : 1 : zipConsecutivesWith (+) fibs
>>>
>>>     -- get the edges of a closed path defined by points (ps):
>>>     edges ps = zipConsecutivesWith makeEdge (ps ++ take 1 ps)
>>>
>>> There are two things to decide:
>>>
>>> 1. Whether this should indeed be added to base (Data.List)
>>> 2. What names we should use in case of inclusion in base
>>>
>>> The proposed functions are:
>>>
>>>     zipConsecutives :: [a] -> [(a,a)]
>>>
>>> and
>>>
>>>     zipConsecutivesWith :: (a -> a -> b) -> [a] -> [b]
>>>
>>> I would not object to some shorter names, such as zipConsecs,
>>> zipConsecsWith etc...
>>>
>>> 2016-05-19 7:37 GMT+02:00 David Feuer <david.feuer at gmail.com>:
>>>
>>>> You promised a collection of use cases. I seem to have missed it. Could
>>>> you send the link again?
>>>> On May 19, 2016 1:35 AM, "Johan Holmquist" <holmisen at gmail.com> wrote:
>>>>
>>>>> The discussion period for this proposal is near (31 of May).
>>>>>
>>>>> So far I count 1 for and 2 against the proposal.
>>>>>
>>>>> Joachim Breitner made a good enumeration of some advantages of adding
>>>>> these to base. Here is an enumeration of pros:
>>>>>
>>>>> * Availability in Data.List gives this pattern a common name.
>>>>>
>>>>> * A common name for this makes code easier to read and decreases the
>>>>> risk of getting the definition wrong.
>>>>>
>>>>> * The argument won't have to be repeated, hence making it easier to
>>>>> chain the functions.
>>>>>
>>>>> * List-fusion potential.
>>>>>
>>>>>
>>>>> Tobias Florek pointed out that `zip <*> tail` can be used to define
>>>>> this inline without the need for repeating the argument and made a
>>>>> reference to the Fairbairn threshold. This is elegant, but I am afraid that
>>>>> people might consider this obscure code golfing if used.
>>>>>
>>>>> Cheers
>>>>> Johan Holmquist
>>>>>
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Henning Thielemann <lemming at henning-thielemann.de>
>>>>> Date: 2016-04-13 13:28 GMT+02:00
>>>>> Subject: Re: Proposal: Add functions to get consecutive elements to
>>>>> Data.List
>>>>> To: Johan Holmquist <holmisen at gmail.com>
>>>>> Cc: Haskell Libraries <libraries at haskell.org>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, 13 Apr 2016, Johan Holmquist wrote:
>>>>>
>>>>> It is not strictly more general because it cannot handle empty
>>>>>> sequences.
>>>>>>
>>>>>
>>>>> Think of it as if it handles the non-[] case.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20160519/602e30d8/attachment-0001.html>