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

[Carter Schonwald]

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 <andreas.abel at ifi.lmu.de>
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 <josephcsible at gmail.com
> > <mailto:josephcsible at gmail.com>> wrote:
> >
> >     On Thu, May 14, 2020 at 10:41 AM Carter Schonwald
> >     <carter.schonwald at gmail.com <mailto:carter.schonwald at 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 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/20200518/e1367378/attachment.html>