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

David Feuer david.feuer at gmail.com
Fri Feb 28 18:55:37 UTC 2020


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 <oleg.grenrus at iki.fi> 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
> > 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/5d35cd3c/attachment.html>


More information about the Libraries mailing list