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

[Carter Schonwald]

Ed, could you clarify what perspective you’re advocating for or against?

On Thu, May 21, 2020 at 3:38 PM Edward Kmett <ekmett at gmail.com> wrote:

> 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/52b12678/attachment.html>