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

Theodore Lief Gannon tanuki at gmail.com
Thu May 19 18:33:50 UTC 2016


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


More information about the Libraries mailing list