<div dir="ltr">Whoops, responded privately (and also made a mistake I wanted to correct, so I guess that works out). To the list this time:<div><br></div><div><span style="font-size:12.8px">I don't like using the 'zip' terminology here; I feel like that should be reserved for multiple distinct data sources.</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Why not 'map2'?</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 19, 2016 at 4:32 AM, Johan Holmquist <span dir="ltr"><<a href="mailto:holmisen@gmail.com" target="_blank">holmisen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Also these two were mentioned earlier (using zipConsecutivesWith):<br><br><div><div><div> -- fibonacci:<br></div><div> 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></div><div>There are two things to decide:<br><br></div><div>1. Whether this should indeed be added to base (Data.List)<br></div><div>2. What names we should use in case of inclusion in base<br><br></div><div>The proposed functions are:<br><br></div><div> zipConsecutives :: [a] -> [(a,a)]<br><br></div><div>and<br><br></div><div> zipConsecutivesWith :: (a -> a -> b) -> [a] -> [b]<br><br></div><div>I would not object to some shorter names, such as zipConsecs, zipConsecsWith etc...<br></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-05-19 7:37 GMT+02:00 David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">You promised a collection of use cases. I seem to have missed it. Could you send the link again?</p>
<div class="gmail_quote"><div><div>On May 19, 2016 1:35 AM, "Johan Holmquist" <<a href="mailto:holmisen@gmail.com" target="_blank">holmisen@gmail.com</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div><div><div><div>The discussion period for this proposal is near (31 of May).<br><br></div>So far I count 1 for and 2 against the proposal.<br><br></div>Joachim Breitner made a good enumeration of some advantages of adding these to base. Here is an enumeration of pros:<br><br></div>* Availability in Data.List gives this pattern a common name.<br></div><div><br>* A common name for this makes code easier to read and decreases the risk of getting the definition wrong.<br><br></div><div>* The argument won't have to be repeated, hence making it easier to chain the functions.<br><br></div>* List-fusion potential.<br><br></div><br>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.<br><br></div><div>Cheers<br></div><div>Johan Holmquist<br></div><div><br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Henning Thielemann</b> <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span><br>Date: 2016-04-13 13:28 GMT+02:00<br>Subject: Re: Proposal: Add functions to get consecutive elements to Data.List<br>To: Johan Holmquist <<a href="mailto:holmisen@gmail.com" target="_blank">holmisen@gmail.com</a>><br>Cc: Haskell Libraries <<a href="mailto:libraries@haskell.org" target="_blank">libraries@haskell.org</a>><br><br><br><span><br>
On Wed, 13 Apr 2016, Johan Holmquist wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is not strictly more general because it cannot handle empty sequences.<br>
</blockquote>
<br></span>
Think of it as if it handles the non-[] case.<br>
</div><br></div></div>
<br></div></div>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">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>
</blockquote></div><br></div>
</div></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><br></div>