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

[David Feuer]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160519/ab05f3c1/attachment.html>