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

[Carter Schonwald]

I'm inclined to think it should be a "must be N" validating , since the
alternative behaviors *will* result in silent data corruption pretty easily.

On Tue, May 12, 2020 at 5:19 AM Andreas Abel <andreas.abel at ifi.lmu.de>
wrote:

> 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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200514/d3b27464/attachment.html>