<div dir="ltr">I'm advocating that fromListN should be able to do basically anything if you violate its contract. It is in GHC.Exts, it isn't in a place marked Safe or Trustworthy, and it is designed to make _fast_ literals. Anything that compromises that mission to do other things, seems ill considered to me, as then you'd have to make the fast thing anyways under another and would lose the ability to get the notation which was the very reason why the class was created in the first place. When used by GHC for desugaring overloaded list literals fromListN <b>never</b> has its contract violated.<div><br></div><div>If you want something safer for manual use where the length is a mere hint, build something safer, then put it in a subclass of IsList. There there are multiple semantics you might want. Do you truncate the list if it is longer than the number of elements supplied? Do you give fewer elements than the number specified if not enough are given to you? Do you just throw an error on length disagreement? Either way you are counting down twice, once on the list, once on the counter, doing potentially twice as much work as you go, possibly walking the list twice like how fromList can delegate to fromListN by computing a length.</div><div><br></div><div>Giving the hint-at-best, crash-at-worst version that at least doesn't segfault its own method name means fromListN and overloaded list literals do not pay for extra protection they do not need, and you can grab your safer version, which unlike fromListN could actually be (re)exported from a Trustworthy module along with the safe parts of IsList. The nice thing about this is that by importing that module the user could use your safer version, and use of OverloadedLists syntax doesn't care about fromListN being in scope.<br><br>The other caveat I had was just that I don't like the fact that IsList mashes toList and fromList together in one class, preventing its use in the case where a list is just one case of several, but this is completely orthogonal to the issue at hand, and if it were ever to be solved would need an issue/proposal in its own right.</div><div><br></div><div>-Edward</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 21, 2020 at 6:53 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">Ed, could you clarify what perspective you’re advocating for or against? </div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 21, 2020 at 3:38 PM Edward Kmett <<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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. <div><br></div><div>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.<div><br></div><div><div>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.</div></div></div></div><div dir="ltr"><div><div><br></div><div>-Edward</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 18, 2020 at 2:59 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">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. </div></div><div dir="auto"><br></div><div dir="auto">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. </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 17, 2020 at 7:45 AM Andreas Abel <<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A question would be how to validate the given length without performance <br>
penalty. The existence of fromListN in addition to fromList is **only** <br>
justified by performance consideration, namely that the length of the <br>
list is known and does not have to be computed.<br>
<br>
In general, it seems that the given length has to be trusted, however, <br>
there might be implementations that can validate the length parameter <br>
as-you-go without additional cost (in the good case that the length is <br>
correctly given).<br>
<br>
On 2020-05-15 21:37, Carter Schonwald wrote:<br>
> validating would *prevent inconsistent data*.<br>
> <br>
> it is precisely the issue that current semantics are *not* consistent <br>
> across that needs to be addressed!<br>
> <br>
> On Thu, May 14, 2020 at 6:38 PM Joseph C. Sible <<a href="mailto:josephcsible@gmail.com" target="_blank">josephcsible@gmail.com</a> <br>
> <mailto:<a href="mailto:josephcsible@gmail.com" target="_blank">josephcsible@gmail.com</a>>> wrote:<br>
> <br>
> On Thu, May 14, 2020 at 10:41 AM Carter Schonwald<br>
> <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a> <mailto:<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>>> wrote:<br>
> > My inclination is we change the semantics of fromListN to be<br>
> strictly validating with an error when the length is wrong. This is<br>
> the most consistent and humane of options.<br>
> <br>
> I disagree that validating would be consistent. Look how common the<br>
> phrases "the precondition is not checked" and "violation of this<br>
> condition is not detected" are in the containers library and so many<br>
> others on Hackage.<br>
> <br>
> Joseph C. Sible<br>
> <br>
> <br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
> <br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>