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@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@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@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@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@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@gmail.com>
Cc: Haskell Libraries <libraries@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries