What do you assume when you see fromListN in a library?

[John Ky]

Oh wow.

I only just realised Data.Primitive.Array.fromListN is defined differently
to Data.Vector.fromListN.

The fromListN
<http://hackage.haskell.org/package/primitive-0.7.0.0/docs/Data-Primitive-Array.html#v:fromListN>
function
takes the input list's length as a hint. Its behaviour should be equivalent
to fromList
<http://hackage.haskell.org/package/primitive-0.7.0.0/docs/Data-Primitive-Array.html#v:fromList>.
The hint can be used to construct the structure l more efficiently compared
to fromList
<http://hackage.haskell.org/package/primitive-0.7.0.0/docs/Data-Primitive-Array.html#v:fromList>.
If the given hint does not equal to the input list's length the behaviour
of fromListN
<http://hackage.haskell.org/package/primitive-0.7.0.0/docs/Data-Primitive-Array.html#v:fromListN>
is
not specified.


On Sat, 29 Feb 2020 at 14:00, Edward Kmett <ekmett at gmail.com> wrote:

> 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.
>
> Right now it is always valid to define `fromListN _ = fromList`. In a
> world with these alternate semantics it would not be.
>
> 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.
>
> -Edward
>
> On Fri, Feb 28, 2020 at 2:03 PM John Ky <newhoggy at gmail.com> wrote:
>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> I do not mind if a function with the current behaviour exists but with a
>> different name like fromListUntilN or something similar.
>>
>> On Fri, 28 Feb 2020 at 16:58, John Ky <newhoggy at gmail.com> wrote:
>>
>>> 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.
>>>
>>> To me size hint is definitely not what I want because it hides
>>> performance/allocation bugs.
>>>
>>> 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.
>>>
>>> On Fri, 28 Feb 2020, 2:41 pm Zemyla, <zemyla at gmail.com> wrote:
>>>
>>>> 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.
>>>>
>>>> On Thu, Feb 27, 2020, 21:31 chessai . <chessai1996 at gmail.com> wrote:
>>>>
>>>>> I expect a list with precisely length N, and reject anything else.
>>>>> IIRC both primitive and vector do this
>>>>>
>>>>> On Thu, Feb 27, 2020, 6:54 PM Carter Schonwald <
>>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>>> Hey everyone:
>>>>>> 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 ?
>>>>>>
>>>>>> Should it reject shorter lists?
>>>>>>
>>>>>> Should it truncate or reject longer lists?
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Thoughts please ?
>>>>>>
>>>>>> -Carter
>>>>>> _______________________________________________
>>>>>> Libraries mailing list
>>>>>> Libraries at haskell.org
>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>>>
>>>>> _______________________________________________
>>>>> Libraries mailing list
>>>>> Libraries at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200229/0faf1c63/attachment.html>