<div dir="ltr"><div><br></div><div><br></div><div>if we could travel back in time, perhaps something like Bardur's Exact vs Hint sum type would be the right way to have had this designed. <br></div><div><br></div><div>possible sites of data corruption / loss are the sortah thing where loud / clear failures should be the baseline. The current api doesnt support that,<br></div><div><br></div><div>My inclination is we change the semantics of fromListN to be strictly validating with an <b>error</b> when the length is wrong. This is the most consistent and humane of options.</div><div><br></div><div>we can still certainly have the additional Exact !Word / Hint !Word api, just it wont be used by folks intiially. but will make the semantical landscape more explicit and let users *choose*</div><div><br></div><div>to repeat: silent truncating/not-validating is bad here. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 29, 2020 at 3:25 AM Edward Kmett <<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Data.Primitive.Array.fromListN is a re-export of base's IsList version, which includes that caveat.<div><br></div><div>Data.Vector exports its own combinator and chooses to provide a stronger rule. It is a perfectly valid definition of `fromListN`, but other instances aren't required to work that way.</div><div><br></div><div>Vector is the odd library out here.</div><div><br></div><div>-Edward</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 29, 2020 at 12:15 AM 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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><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:0px 0px 0px 40px;border:medium 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)" target="_blank">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)" target="_blank">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)" target="_blank">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)" target="_blank">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" target="_blank">ekmett@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color: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-width:1px;border-left-style:solid;border-left-color: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-width:1px;border-left-style:solid;border-left-color: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-width:1px;border-left-style:solid;border-left-color: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-width:1px;border-left-style:solid;border-left-color: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-width:1px;border-left-style:solid;border-left-color: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>
</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>