<div><div><div><div><div dir="auto">Hi all,</div></div><div dir="auto"><br></div><div dir="auto">I would strongly encourage anyone inclined to say things like “<span style="color:rgb(49,49,49);word-spacing:1px">there's no </span><span style="color:rgb(49,49,49);word-spacing:1px">benefit in having the function” to consider reframing the sentiment as “I wouldn’t benefit from having the function, and don’t understand the benefit others will gain.” Once you’ve done that reframe, you can notice that there’s a lack of understanding toward which the appropriate emotional stance is curiosity, not dismissiveness. A lot of people have clearly expressed in this thread that they would benefit from this function, and when you assert as fact that such benefit does not exist, you’re implicitly dismissing and devaluing their experience. </span></div></div></div></div><div dir="auto"><span style="color:rgb(49,49,49);word-spacing:1px"><br></span></div><div dir="auto"><span style="color:rgb(49,49,49);word-spacing:1px">Independent of any technical merits or readability concerns per se, there is a signaling aspect to this discussion. Already this thread has been referenced many times on social media, and it’s sending a very loud signal: “we don’t want you here”. Not because of the content of the discussion, but because of its tone. I happen to think that Haskell is a fantastic language for beginners, and I’ve been watching in real time as potential learners are deciding it isn’t for them. I’ve also been seeing experienced Haskellers deciding it’s not worth it to participate in the libraries process. You can argue as much as you want that people are wrong to get that signal from this thread, that they’re misinterpreting the comments here, etc, but none of that changes the outcome. We can do better than this.</span></div><div dir="auto"><span style="color:rgb(49,49,49);word-spacing:1px"><br></span></div><div dir="auto"><br></div><div dir="auto"><span style="color:rgb(49,49,49);word-spacing:1px">On the proposal itself: I’ve been writing Haskell for several years now and have founded a company that uses Haskell in production, so I’d like to think I’m at least a step or two beyond “beginner”, and yet I cannot recall the last time I saw (:[]) in my code or anyone else’s, and seeing it here caused me to double-take and take a moment to mentally parse it. If that’s the case for me, I’m sure it must be far worse for an actual beginner. Building things by composing primitives is good, but if anyone put this operator into my codebase I’d likely flag it in code review. Readability isn’t about whether it’s possible to read something, it’s about how easy it is to read, and for me this operator doesn’t pass that test. Personally I tend to use pure, but a monomorphic option would be better. I would happily change to using singleton if it becomes available, and am a +1 on the proposal for both List and NonEmpty.</span><span style="color:rgb(49,49,49);word-spacing:1px"><br></span></div><div dir="auto"><span style="color:rgb(49,49,49);word-spacing:1px"><br></span></div><div dir="auto"><br></div><div dir="auto"><span style="color:rgb(49,49,49);word-spacing:1px">Nathan</span></div><div dir="auto"><span style="color:rgb(49,49,49);word-spacing:1px"><br></span></div><div><div><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 21, 2019 at 6:32 AM George Wilson <george@wils.online> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Taylor,<br>
<br>
I'm on the Core Libraries Committee. Thank you for your proposal.<br>
Regarding the +-1 messages in this thread, they are useful to gauge<br>
community opinion, but they are not votes because the libraries<br>
process is not determined by a vote.<br>
<br>
Despite seeming innocuous, the proposed change requires careful<br>
consideration: Data.List is specified by the Haskell Report, so adding<br>
this function would affect the report.<br>
While simple changes to base are typically handled directly by one of<br>
base's maintainers, this change is report-affecting, so it is<br>
"controversial" (as defined in [1]). Hence the CLC is discussing the<br>
proposed change amongst ourselves before a maintainer makes their<br>
decision.<br>
<br>
[1] <a href="https://wiki.haskell.org/Library_submissions" rel="noreferrer" target="_blank">https://wiki.haskell.org/Library_submissions</a><br>
<br>
Cheers,<br>
George<br>
<br>
<br>
<br>
<br>
<br>
On Tue, 20 Aug 2019 at 11:24, Taylor Fausak <<a href="mailto:taylor@fausak.me" target="_blank">taylor@fausak.me</a>> wrote:<br>
><br>
> It has been a week since I submitted my proposal. During that time, 28 people voted, with 16 expressing approval and 12 expressing disapproval. To everyone that voted so far: Thank you! You made for interesting discussion.<br>
><br>
> I still feel that Haskell would be improved by the addition of a `singleton` function to the `Data.List` module. (And also `Data.List.NonEmpty`, even though that wasn't part of my original proposal.) I would be happy to open a merge request adding code, tests, and documentation.<br>
><br>
> I haven't done so yet because I don't know what the next steps are. Can someone from the CLC tell me how an official approval or rejection can be reached, and how long that might take? Thanks!<br>
><br>
> On Mon, Aug 19, 2019, at 6:39 AM, Helmut Schmidt wrote:<br>
><br>
><br>
> Andreas, you seem to be mistaken there'd only be one container API? But there's several container APIs besides "Data.Set" which provide some collection of elements!<br>
><br>
> <a href="https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons</a><br>
><br>
> <a href="https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append</a><br>
><br>
><br>
><br>
><br>
> <a href="https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons</a><br>
><br>
> <a href="https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append</a><br>
><br>
> <a href="http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons" rel="noreferrer" target="_blank">http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons</a><br>
><br>
> <a href="https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons</a><br>
><br>
> <a href="https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append</a><br>
><br>
> Am Mo., 19. Aug. 2019 um 08:16 Uhr schrieb Andreas Abel <<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank">andreas.abel@ifi.lmu.de</a>>:<br>
><br>
> Helmut, do you actually know the container APIs?<br>
><br>
> Show me cons and append in Data.Set!<br>
><br>
> On 2019-08-18 19:40, Helmut Schmidt wrote:<br>
> ><br>
> ><br>
> > Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles<br>
> > <<a href="mailto:ollie@ocharles.org.uk" target="_blank">ollie@ocharles.org.uk</a> <mailto:<a href="mailto:ollie@ocharles.org.uk" target="_blank">ollie@ocharles.org.uk</a>>>:<br>
> ><br>
> >     On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,<br>
> >     <<a href="mailto:helmut.schmidt.4711@gmail.com" target="_blank">helmut.schmidt.4711@gmail.com</a><br>
> >     <mailto:<a href="mailto:helmut.schmidt.4711@gmail.com" target="_blank">helmut.schmidt.4711@gmail.com</a>>> wrote:<br>
> ><br>
> ><br>
> >         All these philosophical arguments calling for "consistency" with<br>
> >         the container APIs or that function need words for the human<br>
> >         mind to comprehend seem short-sighted to me. If we were<br>
> >         consistent about the proposal itself we'd also demand to add<br>
> ><br>
> >            cons = (:)<br>
> ><br>
> >            empty = []<br>
> ><br>
> >            toList = id<br>
> ><br>
> >            fromList = id<br>
> ><br>
> ><br>
> >     I honestly have no problem with any of these.<br>
> ><br>
> ><br>
> > I forgot<br>
> ><br>
> >      append = (++)<br>
> ><br>
> > We also need to address another elephant in the room... those pesky<br>
> > tuples and their special privileged non-wordy syntax!<br>
> ><br>
> >     pair = (,)<br>
> ><br>
> >     triple = (,,)<br>
> ><br>
> >     quadruple = (,,,)<br>
> ><br>
> >     quituple = (,,,,)<br>
> ><br>
> >     sextuple = (,,,,,)<br>
> ><br>
> >     septuble = (,,,,,,)<br>
> ><br>
> >     octuple = (,,,,,,,)<br>
> ><br>
> > If Haskell were invented in this century's EU Haskell source code would<br>
> > be littered with €s instead of $s but then again I wonder why £ wasn't<br>
> > picked. But I digress. We can kill two birds with one stone here:<br>
> ><br>
> >     apply = ($)<br>
> ><br>
> >     strictApply = ($!)<br>
> ><br>
> >     compose = (.)<br>
> ><br>
> ><br>
> > It's fun to imagine how code using those definitions would like! But<br>
> > it's still a -1 for me, sorry!<br>
> ><br>
> ><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>
> _______________________________________________<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>
> _______________________________________________<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>
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>
</div>
</div>
</div>