Reading the OverloadedLists wiki seems to agree with Zemlya. It's not unreasonable at all to treat it as a hint IMO, but we should definitely be consistent, since again, primitive treats any length other than the hint as an error. On Thu, Feb 27, 2020, 7:40 PM Zemyla 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 . 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

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, 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 . 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

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 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 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, 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 . 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

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 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-Arr... 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-Arr.... 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-Arr.... 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-Arr... is not specified.

On Sat, 29 Feb 2020 at 14:00, Edward Kmett 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 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 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, 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 . 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

On Thu, May 14, 2020 at 10:41 AM Carter Schonwald wrote:

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.

I disagree that validating would be consistent. Look how common the phrases "the precondition is not checked" and "violation of this condition is not detected" are in the containers library and so many others on Hackage. Joseph C. Sible

A question would be how to validate the given length without performance penalty. The existence of fromListN in addition to fromList is **only** justified by performance consideration, namely that the length of the list is known and does not have to be computed. In general, it seems that the given length has to be trusted, however, there might be implementations that can validate the length parameter as-you-go without additional cost (in the good case that the length is correctly given). On 2020-05-15 21:37, Carter Schonwald wrote:

validating would *prevent inconsistent data*.

it is precisely the issue that current semantics are *not* consistent across that needs to be addressed!

On Thu, May 14, 2020 at 6:38 PM Joseph C. Sible mailto:josephcsible@gmail.com> wrote:

On Thu, May 14, 2020 at 10:41 AM Carter Schonwald mailto:carter.schonwald@gmail.com> wrote: > 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.

I disagree that validating would be consistent. Look how common the phrases "the precondition is not checked" and "violation of this condition is not detected" are in the containers library and so many others on Hackage.

Joseph C. Sible

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

If you want to make a subclass that exists just to claim those stronger guarantees, fine, but asking existing consumers of this API to give up performance and the invariant that the length of the list matches the number given, is something I'm very strongly against. It seems that the thing that is requesting the extra functionality should pay for it via subclassing and either providing another method, or incurring extra laws for the superclass method. I have a general preference for making the operation with the extra laws have another name and be an inhabitant of the subclass, though, because then users aren't hoist on the horns of the dilemma of which semantics they want their fromListN to have. They don't have to choose between speed and being able to implement the subclass. Mind you IsList is a terrible class. I _really_ wish toList could be allowed to fail, or could be moved to a separate class, then you could use it in syntax trees where one of the cases was list like and what not. We can use fromString in all sorts of places where fromList cannot be used because of this self-correcting embedding/projection-like constraint. -Edward On Mon, May 18, 2020 at 2:59 PM Carter Schonwald wrote:

The problem is that some implementations will silently truncate data, and while the original reason for the interface was desugaring list notation to a different data structure, it’s now used for other things.

Frankly, the main performance win was meant to be with respect to single round of data structure allocation/ associated fragmentation. For a statically known list.

On Sun, May 17, 2020 at 7:45 AM Andreas Abel wrote:

...

A question would be how to validate the given length without performance penalty. The existence of fromListN in addition to fromList is **only** justified by performance consideration, namely that the length of the list is known and does not have to be computed.

In general, it seems that the given length has to be trusted, however, there might be implementations that can validate the length parameter as-you-go without additional cost (in the good case that the length is correctly given).

On 2020-05-15 21:37, Carter Schonwald wrote:

...

validating would *prevent inconsistent data*.

it is precisely the issue that current semantics are *not* consistent across that needs to be addressed!

On Thu, May 14, 2020 at 6:38 PM Joseph C. Sible mailto:josephcsible@gmail.com> wrote:

On Thu, May 14, 2020 at 10:41 AM Carter Schonwald mailto:carter.schonwald@gmail.com> wrote: > 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.

I disagree that validating would be consistent. Look how common the phrases "the precondition is not checked" and "violation of this condition is not detected" are in the containers library and so many others on Hackage.

Joseph C. Sible

_______________________________________________ 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

I'm advocating that fromListN should be able to do basically anything if you violate its contract. It is in GHC.Exts, it isn't in a place marked Safe or Trustworthy, and it is designed to make _fast_ literals. Anything that compromises that mission to do other things, seems ill considered to me, as then you'd have to make the fast thing anyways under another and would lose the ability to get the notation which was the very reason why the class was created in the first place. When used by GHC for desugaring overloaded list literals fromListN *never* has its contract violated. If you want something safer for manual use where the length is a mere hint, build something safer, then put it in a subclass of IsList. There there are multiple semantics you might want. Do you truncate the list if it is longer than the number of elements supplied? Do you give fewer elements than the number specified if not enough are given to you? Do you just throw an error on length disagreement? Either way you are counting down twice, once on the list, once on the counter, doing potentially twice as much work as you go, possibly walking the list twice like how fromList can delegate to fromListN by computing a length. Giving the hint-at-best, crash-at-worst version that at least doesn't segfault its own method name means fromListN and overloaded list literals do not pay for extra protection they do not need, and you can grab your safer version, which unlike fromListN could actually be (re)exported from a Trustworthy module along with the safe parts of IsList. The nice thing about this is that by importing that module the user could use your safer version, and use of OverloadedLists syntax doesn't care about fromListN being in scope. The other caveat I had was just that I don't like the fact that IsList mashes toList and fromList together in one class, preventing its use in the case where a list is just one case of several, but this is completely orthogonal to the issue at hand, and if it were ever to be solved would need an issue/proposal in its own right. -Edward On Thu, May 21, 2020 at 6:53 PM Carter Schonwald wrote:

Ed, could you clarify what perspective you’re advocating for or against?

On Thu, May 21, 2020 at 3:38 PM Edward Kmett wrote:

...

If you want to make a subclass that exists just to claim those stronger guarantees, fine, but asking existing consumers of this API to give up performance and the invariant that the length of the list matches the number given, is something I'm very strongly against.

It seems that the thing that is requesting the extra functionality should pay for it via subclassing and either providing another method, or incurring extra laws for the superclass method. I have a general preference for making the operation with the extra laws have another name and be an inhabitant of the subclass, though, because then users aren't hoist on the horns of the dilemma of which semantics they want their fromListN to have. They don't have to choose between speed and being able to implement the subclass.

Mind you IsList is a terrible class. I _really_ wish toList could be allowed to fail, or could be moved to a separate class, then you could use it in syntax trees where one of the cases was list like and what not. We can use fromString in all sorts of places where fromList cannot be used because of this self-correcting embedding/projection-like constraint.

-Edward

On Mon, May 18, 2020 at 2:59 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

The problem is that some implementations will silently truncate data, and while the original reason for the interface was desugaring list notation to a different data structure, it’s now used for other things.

Frankly, the main performance win was meant to be with respect to single round of data structure allocation/ associated fragmentation. For a statically known list.

On Sun, May 17, 2020 at 7:45 AM Andreas Abel wrote:

...

A question would be how to validate the given length without performance penalty. The existence of fromListN in addition to fromList is **only** justified by performance consideration, namely that the length of the list is known and does not have to be computed.

In general, it seems that the given length has to be trusted, however, there might be implementations that can validate the length parameter as-you-go without additional cost (in the good case that the length is correctly given).

...

validating would *prevent inconsistent data*.

it is precisely the issue that current semantics are *not* consistent across that needs to be addressed!

On Thu, May 14, 2020 at 6:38 PM Joseph C. Sible < josephcsible@gmail.com mailto:josephcsible@gmail.com> wrote:

On Thu, May 14, 2020 at 10:41 AM Carter Schonwald mailto:carter.schonwald@gmail.com> wrote: > 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.

I disagree that validating would be consistent. Look how common

On 2020-05-15 21:37, Carter Schonwald wrote: the

...

phrases "the precondition is not checked" and "violation of this condition is not detected" are in the containers library and so

many

...

others on Hackage.

Joseph C. Sible

_______________________________________________ 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

I agree with others who have stated that the interpretation as a hint is bad for performance. My intuition has always been that we pre-allocate an array of length N, fill that in with a recursive function while accumulating the length, and rejecting anything incorrect. I think the motivation behind it being a hint is still mostly a mystery to me, until I can find some discussion. I can see how a hint might be useful from the perspective of the desugarer, but for people who are calling fromListN in source code, this seems much less intuitive, if not potentially useful. It might be illuminating if we could find some discussion about why this decision was made, since there might be something more I'm not considering. As it stands, my intuition (and that of most library authors I know, and most libraries I have seen) does not align with that as a hint. E.g. if primitive were to switch to treating N as a hint, it would require a majour version bump, and also it would be a place where a size hint would be most unwelcome because of perf. On Fri, Feb 28, 2020, 7:02 AM Bardur Arantsson wrote:

On 28/02/2020 04.40, Zemyla 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.

One option would be to have a

data Size = Hint Int | Exact Int

as a parameter and let the user specify desired behavior. (Assuming it's easy to accomodate either.)

Regards,

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

The motivation is that it would be used with the OverloadedLists extension, and the size would be filled in by the compiler. On Fri, Feb 28, 2020, 04:11 Andrew Lelechenko wrote:

From the top of my head, I would expect that fromListN rejects both shorter and longer lists. If a user is under a wrong impression that some list has length N, it is better to fail early, before other, more dangerous implications of this impression are made (for example, using `unsafeIndex`).

However, my expectations disagree with the documentation, which states that the observable behaviour of fromListN should be equivalent to fromList: http://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Exts.html#v:fromLi... I am not sure what was the motivation behind such choice.

Best regards, Andrew

On 28 Feb 2020, at 02:53, Carter Schonwald 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

There are at least two reasonable sorts of hint: upper bounds and lower bounds. For arrays, either can be useful, but upper bounds are especially nice in combination with resizing primitives (currently only available for SmallArray and ByteArray-backed arrays). For sequences, lower bounds are useful, but upper bounds aren't really. On Fri, Feb 28, 2020, 1:49 PM Oleg Grenrus wrote:

My personal expectations may be different based on what the container in question is. Elsewhere in the discussion types in `primitive` and `vector` were mentioned. They are however different.

Compare to C++ code snippets, which are all morally `fromList(N)`:

std::array variantA; for (int i = 0; i < 100; i++) { primitive[i] = f(i); }

// not good std::vector<int> variantB; for (int i = 0; i < 100; i++) { primitive.push_back(f(i)); }

std::vector<int> variantC; variantC.reserve(100); for (int i = 0; i < 100; i++) { primitive.push_back(f(i)); }

I'm not a fan of changing `fromListN` to be partial function, but if that change is carried on in `vector` there should be a variant which allows to `reserve` without worrying about partiality.

- Oleg

On 28.2.2020 4.53, Carter Schonwald 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

On 28/02/2020 21.01, Bardur Arantsson wrote:

On 28/02/2020 19.48, Oleg Grenrus wrote:

...

    std::vector<int> variantC;     variantC.reserve(100);     for (int i = 0; i < 100; i++) {        primitive.push_back(f(i));     }

I'm not a fan of changing `fromListN` to be partial function, but if that change is carried on in `vector` there should be a variant which allows to `reserve` without worrying about partiality.

- Oleg

Interestingly, reserve actually is a size hint in the sense of "must be equal or greater than".

(Apogies for the self-reply, I fired that one off a bit early.) That said, the expectation in C++ is the you *will* be mutating a vector, so expecting further push_back(), etc. might be reasonable. In 'vector', maybe not so much? Regards,

On 2020-05-12 02:51, Andrew Lelechenko wrote:

I find the existing description in GHC.Exts self-contradictory, or at least of unclear interpretation. It says:

"The fromListN function takes the input list's length as a hint. Its behaviour should be equivalent to fromList.”

Here, it should relativize to: ... provided the hint is correct, i.e., is the correct length of the list. If this half-sentence is added, then the description seems to say what you say in alternative 2.

This phrase sounds like fromListN should not reject shorter or truncate longer lists, which makes fromListN in vector (and other libraries) incorrect. But then the description goes on:

"The hint can be used to construct the structure l more efficiently compared to fromList. If the given hint does not equal to the input list's length the behaviour of fromListN is not specified”

Which means that actually fromListN can reject shorter lists, truncate longer lists or launch missiles, and makes fromListN in vector perfectly valid.

I suggest we fix this ambiguity. There are two ways to do it:

1. We require that the first argument of fromListN is treated only as a hint, and fromListN N is observably equivalent to fromList, even when N does not match the length of the list, removing the last sentence about undefined behaviour. Such interpretation means that we need to fix vector (and other) packages; in many cases there is no way to define such fromListN more efficient than fromList.

2. We require that the first argument of fromListN is not a hint, but must-must-must match the length of the list, otherwise undefined behaviour happens (UB allows to retain fromListN = const fromList as the default definition). Such interpretation matches existing implementations and, I think, matches the intuition of most package authors.

What do you think?

Best regards, Andrew

...

On 28 Feb 2020, at 02:53, Carter Schonwald 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