<p dir="ltr">Hi there,</p>
<p dir="ltr">The idiom I normally use for this is 'zip xs (drop 1 xs)'. By using 'drop 1' instead of 'tail' it handles the empty case without partiality or needing an extra equation. Does that work for you?</p>
<p dir="ltr">Cheers,</p>
<p dir="ltr">David</p>
<div class="gmail_quote">On 12 Apr 2016 21:55, "Johan Holmquist" <<a href="mailto:holmisen@gmail.com">holmisen@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I propose adding two new functions to Data.List:<br><br>    zipConsecutives :: [a] -> [(a,a)]<br>    zipConsecutives xs = zip xs (tail xs)<br><br>    zipConsecutivesWith :: (a -> a -> b) -> [a] -> [b]<br>    zipConsecutivesWith f xs = zipWith f xs (tail xs)<br><br>(with possibly more efficient implementations)<br><br>The Trac feature request is at <a href="https://ghc.haskell.org/trac/ghc/ticket/11815" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/11815</a>.<br><br><br>Why<br><br>These functions are useful when one wants to process consecutive pairs<br>of elements in a sequence, which is not uncommon. The ticket lists<br>some examples, reiterated here:<br><br>    -- diff consecutive elements:<br>    diffs = zipConsecutivesWith (flip (-))<br><br>    -- determine if list is ascending (similar for descending and strict):<br>    isAscending = and . zipConsecutivesWith (<=)<br><br>    -- an old friend of ours:<br>    fibs = 1 : 1 : zipConsecutivesWith (+) fibs<br><br>    -- get the edges of a closed path defined by points (ps):<br>    edges ps = zipConsecutivesWith makeEdge (ps ++ take 1 ps)<br><br><br>Why add to Data.List (and base)<br><br>The definition must either use an extra equation for the empty list case:<br><br>    zipConsecutives [] = []<br>    zipConsecutives xs = zip xs (tail xs)<br><br>which makes it non practical to define inline at each use site. Or one<br>may omit the empty list equation, which is safe (thanks to laziness),<br>but that may not be immediately obvious. (It wasn't to me anyway.) The<br>tail function is generally considered unsafe so it is not desirable to<br>force the user to use it. The proposed functions would offer an<br>alternative.<br><br><br>The Data.List module is often imported unqualified, so new identifiers<br>may cause collissions. I do find it rather unlikely that the proposed<br>names would cause such problems, however.<br><br><br>Deadline for discussion: 2016-05-31.<br></div>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div>