<div dir="ltr">I'm inclined to think it should be a "must be N" validating , since the alternative behaviors *will* result in silent data corruption pretty easily.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 12, 2020 at 5:19 AM Andreas Abel <<a href="mailto:andreas.abel@ifi.lmu.de">andreas.abel@ifi.lmu.de</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">On 2020-05-12 02:51, Andrew Lelechenko wrote:<br>
> I find the existing description in GHC.Exts self-contradictory, or at least of unclear interpretation. It says:<br>
> <br>
> "The fromListN function takes the input list's length as a hint. Its behaviour should be equivalent to fromList.”<br>
<br>
Here, it should relativize to:<br>
<br>
    ... provided the hint is correct, i.e., is the correct length of the <br>
list.<br>
<br>
If this half-sentence is added, then the description seems to say what <br>
you say in alternative 2.<br>
<br>
> This phrase sounds like fromListN should not reject shorter or truncate longer lists, which makes fromListN in vector (and other libraries) incorrect. But then the description goes on:<br>
> <br>
> "The hint can be used to construct the structure l more efficiently compared to fromList. If the given hint does not equal to the input list's length the behaviour of fromListN is not specified”<br>
> <br>
> Which means that actually fromListN can reject shorter lists, truncate longer lists or launch missiles, and makes fromListN in vector perfectly valid.<br>
> <br>
> I suggest we fix this ambiguity. There are two ways to do it:<br>
> <br>
> 1. We require that the first argument of fromListN is treated only as a hint, and fromListN N is observably equivalent to fromList, even when N does not match the length of the list, removing the last sentence about undefined behaviour. Such interpretation means that we need to fix vector (and other) packages; in many cases there is no way to define such fromListN more efficient than fromList.<br>
> <br>
> 2. We require that the first argument of fromListN is not a hint, but must-must-must match the length of the list, otherwise undefined behaviour happens (UB allows to retain fromListN = const fromList as the default definition). Such interpretation matches existing implementations and, I think, matches the intuition of most package authors.<br>
> <br>
> What do you think?<br>
> <br>
> Best regards,<br>
> Andrew<br>
> <br>
>> On 28 Feb 2020, at 02:53, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br>
>><br>
>> Hey everyone:<br>
>> 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 ?<br>
>><br>
>> Should it reject shorter lists?<br>
>><br>
>> Should it truncate or reject longer lists?<br>
>><br>
>> 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.<br>
>><br>
>> Thoughts please ?<br>
>><br>
>> -Carter<br>
> <br>
> _______________________________________________<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>
_______________________________________________<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>