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

[Edward Kmett]

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 at 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 <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
>>
> _______________________________________________
> 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/20200521/17af788b/attachment.html>