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

Sat Feb 29 08:24:39 UTC 2020

Data.Primitive.Array.fromListN is a re-export of base's IsList version,
which includes that caveat.

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.

Vector is the odd library out here.

-Edward

On Sat, Feb 29, 2020 at 12:15 AM John Ky <newhoggy at gmail.com> wrote:

> 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/2439e880/attachment.html>