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

[Edward Kmett]

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/20200228/7af482ae/attachment.html>