<div dir="ltr"><div dir="ltr">Oh wow.</div><div dir="ltr"><br></div><div>I only just realised <font face="monospace">Data.Primitive.Array.fromListN</font> is defined differently to <font face="monospace">Data.Vector.fromListN</font>.</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px">The </span><code style="margin:0px;padding:0px;line-height:16.12px;color:rgb(0,0,0);font-size:13px"><a href="http://hackage.haskell.org/package/primitive-0.7.0.0/docs/Data-Primitive-Array.html#v:fromListN" title="Data.Primitive.Array" style="margin:0px;padding:0px;text-decoration-line:none;color:rgb(171,105,84)">fromListN</a></code><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px"> function takes the input list's length as a hint. Its behaviour should be equivalent to </span><code style="margin:0px;padding:0px;line-height:16.12px;color:rgb(0,0,0);font-size:13px"><a href="http://hackage.haskell.org/package/primitive-0.7.0.0/docs/Data-Primitive-Array.html#v:fromList" title="Data.Primitive.Array" style="margin:0px;padding:0px;text-decoration-line:none;color:rgb(171,105,84)">fromList</a></code><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px">. The hint can be used to construct the structure </span><code style="margin:0px;padding:0px;line-height:16.12px;color:rgb(0,0,0);font-size:13px">l</code><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px"> more efficiently compared to </span><code style="margin:0px;padding:0px;line-height:16.12px;color:rgb(0,0,0);font-size:13px"><a href="http://hackage.haskell.org/package/primitive-0.7.0.0/docs/Data-Primitive-Array.html#v:fromList" title="Data.Primitive.Array" style="margin:0px;padding:0px;text-decoration-line:none;color:rgb(171,105,84)">fromList</a></code><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px">. If the given hint does not equal to the input list's length the behaviour of </span><code style="margin:0px;padding:0px;line-height:16.12px;color:rgb(0,0,0);font-size:13px"><a href="http://hackage.haskell.org/package/primitive-0.7.0.0/docs/Data-Primitive-Array.html#v:fromListN" title="Data.Primitive.Array" style="margin:0px;padding:0px;text-decoration-line:none;color:rgb(171,105,84)">fromListN</a></code><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px"> is not specified.</span></div></blockquote><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 29 Feb 2020 at 14:00, Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Currently the documented behavior of fromListN is undefined when n is not equal to the list length, so you're basically asking for a change in library semantics. I'm rather uncomfortable broadening fromListN's mandate as it is mainly an implementation detail for OverloadedLists that has been hijacked by users for efficiency here and there. <div><br>Right now it is always valid to define `fromListN _ = fromList`. In a world with these alternate semantics it would not be.<br><br></div><div><div>Your "fromListUntilN" is a rather complicated beast, because it needs to be able to trim or pad if the list is too short, and take if it is too long, and you still have to handle the drop for chunking. This is asking for way more structure than fromListN which is basically just telling the vector or whatever exactly the final size. It is probably best to try to write the custom combinator that does the right thing maintaining a current mutable vector and trimming or padding the last one, than to burden an optimization for a piece of syntactic sugar with more complex semantics AND completely break the ability to ignore that this optimization exists.</div><div><br><div></div></div><div><div></div></div><div>-Edward</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 28, 2020 at 2:03 PM John Ky <<a href="mailto:newhoggy@gmail.com" target="_blank">newhoggy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I should add that one of my actual use cases is to take a list of unknown length and chunk it into a list of fixed sized vectors.<div><br></div><div>I use fromListN which allows me to fill a vector up until N and then I move onto the next one etc until the list is exhausted.</div><div><br></div><div>Requiring an exact N is a pessimisation for me because it would force me to create intermediate lists of the desired size before calling fromListN.</div><div><br></div><div>I do not mind if a function with the current behaviour exists but with a different name like fromListUntilN or something similar.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 28 Feb 2020 at 16:58, John Ky <<a href="mailto:newhoggy@gmail.com" target="_blank">newhoggy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>I expect it to pre-allocate space for N elements and populate the vector until there are no more elements or the vector is full and return a vector that has a size the minimum of the length of the input list and N.</div><div dir="auto"><br></div><div dir="auto">To me size hint is definitely not what I want because it hides performance/allocation bugs.</div><div dir="auto"><br></div><div dir="auto">If it is possible to modify the function type then I would have it return a tuple of a vector with maximum size N as well as the remainder of the list.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, 28 Feb 2020, 2:41 pm Zemyla, <<a href="mailto:zemyla@gmail.com" target="_blank">zemyla@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">I'm kind of the opposite. I think the number given to fromListN should be a "size hint", not a redundant coding of the size of the list given.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 27, 2020, 21:31 chessai . <<a href="mailto:chessai1996@gmail.com" rel="noreferrer" target="_blank">chessai1996@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">I expect a list with precisely length N, and reject anything else. IIRC both primitive and vector do this</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 27, 2020, 6:54 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" rel="noreferrer noreferrer" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hey everyone: </div><div dir="auto">When you see fromListN as a function in a library, do you assume / presume it’s expecting an exactly N element list ? Or do you expect/tolerate other behavior ? </div><div dir="auto"><br></div><div dir="auto">Should it reject shorter lists?</div><div dir="auto"><br></div><div dir="auto">Should it truncate or reject longer lists? </div><div dir="auto"><br></div><div dir="auto">A corner case of this came up in some bug discussion I was having regarding vector,  and I shall claim and or presume that most folks assume exact size with prompt rejection of too long or too short. </div><div dir="auto"><br></div><div dir="auto">Thoughts please ?</div><div dir="auto"><br></div><div dir="auto">-Carter </div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div></div>
</blockquote></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>
</blockquote></div>
</blockquote></div></div>