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

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

chessai .
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

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

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

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

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Georg Rudoy
In reply to this post by Carter Schonwald
чт, 27 февр. 2020 г. в 21:54, Carter Schonwald <[hidden email]>:
> Should it reject shorter lists?

Definitely (although it depends on the definition of "reject" — but
I'm even fine with the function being partial there).

> Should it truncate or reject longer lists?

I'd expect it to "truncate", unless "reject" implies performance
benefits (but I couldn't come up with a good example where it does
imply those).



--
  Georg Rudoy
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer
In reply to this post by Zemyla
Trying to deal cleanly with incorrect sizes, treated as hints, could have performance consequences. I'm not sure how bad they'll be.

On Thu, Feb 27, 2020, 10:40 PM Zemyla <[hidden email]> 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 . <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

John Ky
In reply to this post by Zemyla
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, <[hidden email]> 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 . <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Andrew Lelechenko
In reply to this post by Carter Schonwald
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:fromListN I am not sure what was the motivation behind such choice.

Best regards,
Andrew

On 28 Feb 2020, at 02:53, Carter Schonwald <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Zemyla
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 <[hidden email]> 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:fromListN I am not sure what was the motivation behind such choice.

Best regards,
Andrew

On 28 Feb 2020, at 02:53, Carter Schonwald <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Bardur Arantsson-2
In reply to this post by Zemyla
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

chessai .
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Zemyla
Honestly, we could probably have positive numbers mean "do this number exactly" and negative numbers mean "use this as a hint". For instance:

filter p arr = fromListN (negate $ length arr) $ Prelude.filter p $ toList arr

This is an increase in definedness, since normally most implementations would error when provided a negative length.


On Fri, Feb 28, 2020, 09:11 chessai . <[hidden email]> wrote:
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Oleg Grenrus
In reply to this post by Carter Schonwald
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<int, 100> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

David Feuer
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 <[hidden email]> 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<int, 100> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Eric Mertens
In reply to this post by Carter Schonwald
I think we should have the functions exist that make sense to implement. If having a function with a length hint helps perform more efficient allocation of vectors then let's have one.

I’d prefer that we simply picked a name that fit the behavior we wanted than picked behavior to fit the name. If it’s unclear what “fromListN” does, then let’s make “fromListWithSizeHint” or “fromListExactN" or something slightly shorter.

If we want to avoid partial functions we can take a default element “fromListWithLengthWithDefault” used to pad out the missing elements and then debate what a nice name might be.

> On Feb 27, 2020, at 6:53 PM, Carter Schonwald <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Bardur Arantsson-2
In reply to this post by Oleg Grenrus
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".

(According to cppreference.com, anway.)

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Bardur Arantsson-2
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,

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
In reply to this post by Carter Schonwald
I treat any use of a list of length other than N as an error. 

On Thu, Feb 27, 2020 at 6:54 PM Carter Schonwald <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

John Ky
In reply to this post by John Ky
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 <[hidden email]> 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, <[hidden email]> 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 . <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
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 <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> 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 . <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
12