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@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@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@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@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@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries