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

Thu May 14 14:28:22 UTC 2020

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.

possible sites of data corruption / loss are the sortah thing where loud /
clear failures should be the baseline. The current api doesnt support that,

My inclination is we change the semantics of fromListN to be strictly
validating with an *error* when the length is wrong. This is the most
consistent and humane of options.

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*

to repeat: silent truncating/not-validating is bad here.

On Sat, Feb 29, 2020 at 3:25 AM Edward Kmett <ekmett at gmail.com> wrote:

> 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
>>>>
>>> _______________________________________________
> 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/20200514/5c22ebe3/attachment.html>