<div dir="ltr">Since this has remained contentious, I'd like to contribute my +1 to the argument, and to express my support for the points that Nathan and Matt have raised. To this point in the discussion, however, I have not seen raised the perspective that I hold, and so I'm going to add another color to the bikeshed.<br><br>My point of view here is informed by my efforts to teach my children to program, using Haskell. <br><br>In every case where we define a typeclass instance, we write the implementation of that instance as a number of monomorphic functions. My position is that these monomorphic functions should always be exported directly, perhaps from an `.Internal` module. <br><br>My preferred way of writing typeclass instances is just this: I create two modules, `Foo.Bar` and `Foo.Bar.Internal`. `Foo.Bar` is used only to selectively reexport from `Foo.Bar.Internal`, which is where the relevant types and typeclass instances are defined. For each typeclass method to be implemented, I define a top-level monomorphic function, and this function is used in the implementation of the instance; in this case, it would look like:<br><br>module Data.List.Internal where<br> ...<br><br> singleton :: x -> [x]<br> singleton x = [x]<br><br>instance Applicative [] where<br> pure = singleton<br> ...<br><br>When followed consistently, this gives the end user the greatest flexibility in choosing whether to use the monomorphic version (in a context where they want the compiler to alert them if the type changes) or the polymorphic one. I dearly wish, for example, that this approach were followed in `Data.Time.Clock`, for example, where a good deal of the important functionality is awkwardly hidden in `Num` and `Integral` instances (which, as an aside, are highly inappropriate).<br><br>In conclusion, I think that the proposal for Data.List.singleton is a good one - I just wish that it went a great deal further.<br><br>Kris</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 21, 2019 at 6:32 AM Taylor Fausak <<a href="mailto:taylor@fausak.me">taylor@fausak.me</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"><u></u><div><div>Thanks for saying that, Nathan! I agree wholeheartedly.<br></div><div><br></div><div>To George and the CLC: I'm disappointed to hear that I inadvertently suggested something that would require changing the Haskell Language Report. It is my understanding that work on the report has more or less stalled [1], and I would hate for this simple addition to be caught in that quagmire.<br></div><div><br></div><div>Your mention of the report encouraged me to look for differences between the current Data.List module and the one specified in the report [2]. Aside from the obvious Foldable/Traversable changes brought by the FTP proposal, it didn't take long to find a difference: the uncons function [3]. I found its source in GHC.List [4], which pointed me to a Trac issue [5], a mailing list thread [6], and a Phabricator differential [7].<br></div><div><br></div><div>I bring this up not because I expect the process to be exactly the same today as it was five years ago, but because the simple addition of the uncons function was accepted without nearly as much discussion. Also it was notably accepted without any mention of the report at all. Has something changed in the meantime, or did I suggest something that hit a nerve with the community?<br></div><div><br></div><div>Regardless, I'm happy to hear that the CLC is considering my proposal among themselves. Is there an expected timeline? (I'm looking for a rough order of magnitude, not an exact date.) Thanks!<br></div><div><br></div><div>1: <a href="https://github.com/haskell/rfcs/issues/15" target="_blank">https://github.com/haskell/rfcs/issues/15</a><br></div><div>2: <a href="https://www.haskell.org/onlinereport/haskell2010/haskellch20.html#x28-22800020" target="_blank">https://www.haskell.org/onlinereport/haskell2010/haskellch20.html#x28-22800020</a><br></div><div>3: <a href="https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-List.html#v:uncons" target="_blank">https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-List.html#v:uncons</a><br></div><div>4: <a href="https://gitlab.haskell.org/ghc/ghc/blob/83ca42de519cdfa28b38164e90d726034dba768e/libraries/base/GHC/List.hs#L65-72" target="_blank">https://gitlab.haskell.org/ghc/ghc/blob/83ca42de519cdfa28b38164e90d726034dba768e/libraries/base/GHC/List.hs#L65-72</a><br></div><div>5: <a href="https://gitlab.haskell.org/ghc/ghc/issues/9550" target="_blank">https://gitlab.haskell.org/ghc/ghc/issues/9550</a><br></div><div>6: <a href="https://mail.haskell.org/pipermail/libraries/2014-July/023314.html" target="_blank">https://mail.haskell.org/pipermail/libraries/2014-July/023314.html</a><br></div><div>7: <a href="https://phabricator.haskell.org/D195" target="_blank">https://phabricator.haskell.org/D195</a><br></div><div><br></div><div>On Wed, Aug 21, 2019, at 6:22 AM, Nathan Bouscal wrote:<br></div><blockquote type="cite" id="gmail-m_2002750646839835631qt"><div><div><div><div><div dir="auto">Hi all,<br></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)" class="gmail-m_2002750646839835631colour">there's no </span><span style="color:rgb(49,49,49)" class="gmail-m_2002750646839835631colour">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><br></div></div></div></div><div dir="auto"><span style="color:rgb(49,49,49)" class="gmail-m_2002750646839835631colour"></span><br></div><div dir="auto"><span style="color:rgb(49,49,49)" class="gmail-m_2002750646839835631colour">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><br></div><div dir="auto"><span style="color:rgb(49,49,49)" class="gmail-m_2002750646839835631colour"></span><br></div><div dir="auto"><br></div><div dir="auto"><span style="color:rgb(49,49,49)" class="gmail-m_2002750646839835631colour">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)" class="gmail-m_2002750646839835631colour"></span><br></div><div dir="auto"><span style="color:rgb(49,49,49)" class="gmail-m_2002750646839835631colour"></span><br></div><div dir="auto"><br></div><div dir="auto"><span style="color:rgb(49,49,49)" class="gmail-m_2002750646839835631colour">Nathan</span><br></div><div dir="auto"><span style="color:rgb(49,49,49)" class="gmail-m_2002750646839835631colour"></span><br></div><div><div><div><div><div><br></div><div class="gmail-m_2002750646839835631qt-gmail_quote"><div class="gmail-m_2002750646839835631qt-gmail_attr" dir="ltr">On Wed, Aug 21, 2019 at 6:32 AM George Wilson <george@wils.online> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail-m_2002750646839835631qt-gmail_quote"><div>Hi Taylor,<br></div><div> <br></div><div> I'm on the Core Libraries Committee. Thank you for your proposal.<br></div><div> Regarding the +-1 messages in this thread, they are useful to gauge<br></div><div> community opinion, but they are not votes because the libraries<br></div><div> process is not determined by a vote.<br></div><div> <br></div><div> Despite seeming innocuous, the proposed change requires careful<br></div><div> consideration: Data.List is specified by the Haskell Report, so adding<br></div><div> this function would affect the report.<br></div><div> While simple changes to base are typically handled directly by one of<br></div><div> base's maintainers, this change is report-affecting, so it is<br></div><div> "controversial" (as defined in [1]). Hence the CLC is discussing the<br></div><div> proposed change amongst ourselves before a maintainer makes their<br></div><div> decision.<br></div><div> <br></div><div> [1] <a rel="noreferrer" href="https://wiki.haskell.org/Library_submissions" target="_blank">https://wiki.haskell.org/Library_submissions</a><br></div><div> <br></div><div> Cheers,<br></div><div> George<br></div><div> <br></div><div> <br></div><div> <br></div><div> <br></div><div> <br></div><div> On Tue, 20 Aug 2019 at 11:24, Taylor Fausak <<a href="mailto:taylor@fausak.me" target="_blank">taylor@fausak.me</a>> wrote:<br></div><div> ><br></div><div> > 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></div><div> ><br></div><div> > 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></div><div> ><br></div><div> > 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></div><div> ><br></div><div> > On Mon, Aug 19, 2019, at 6:39 AM, Helmut Schmidt wrote:<br></div><div> ><br></div><div> ><br></div><div> > 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></div><div> ><br></div><div> > <a rel="noreferrer" href="https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons" target="_blank">https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:cons</a><br></div><div> ><br></div><div> > <a rel="noreferrer" href="https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append" target="_blank">https://hackage.haskell.org/package/dlist-0.8.0.7/docs/Data-DList.html#v:append</a><br></div><div> ><br></div><div> ><br></div><div> ><br></div><div> ><br></div><div> > <a rel="noreferrer" href="https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons" target="_blank">https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:cons</a><br></div><div> ><br></div><div> > <a rel="noreferrer" href="https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append" target="_blank">https://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:append</a><br></div><div> ><br></div><div> > <a rel="noreferrer" href="http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons" target="_blank">http://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector.html#v:cons</a><br></div><div> ><br></div><div> > <a rel="noreferrer" href="https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons" target="_blank">https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:cons</a><br></div><div> ><br></div><div> > <a rel="noreferrer" href="https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append" target="_blank">https://hackage.haskell.org/package/bytestring-0.10.10.0/docs/Data-ByteString.html#v:append</a><br></div><div> ><br></div><div> > 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></div><div> ><br></div><div> > Helmut, do you actually know the container APIs?<br></div><div> ><br></div><div> > Show me cons and append in Data.Set!<br></div><div> ><br></div><div> > On 2019-08-18 19:40, Helmut Schmidt wrote:<br></div><div> > ><br></div><div> > ><br></div><div> > > Am So., 18. Aug. 2019 um 17:17 Uhr schrieb Oliver Charles<br></div><div> > > <<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></div><div> > ><br></div><div> > > On Sun, 18 Aug 2019, 5:47 pm Helmut Schmidt,<br></div><div> > > <<a href="mailto:helmut.schmidt.4711@gmail.com" target="_blank">helmut.schmidt.4711@gmail.com</a><br></div><div> > > <mailto:<a href="mailto:helmut.schmidt.4711@gmail.com" target="_blank">helmut.schmidt.4711@gmail.com</a>>> wrote:<br></div><div> > ><br></div><div> > ><br></div><div> > > All these philosophical arguments calling for "consistency" with<br></div><div> > > the container APIs or that function need words for the human<br></div><div> > > mind to comprehend seem short-sighted to me. If we were<br></div><div> > > consistent about the proposal itself we'd also demand to add<br></div><div> > ><br></div><div> > > cons = (:)<br></div><div> > ><br></div><div> > > empty = []<br></div><div> > ><br></div><div> > > toList = id<br></div><div> > ><br></div><div> > > fromList = id<br></div><div> > ><br></div><div> > ><br></div><div> > > I honestly have no problem with any of these.<br></div><div> > ><br></div><div> > ><br></div><div> > > I forgot<br></div><div> > ><br></div><div> > > append = (++)<br></div><div> > ><br></div><div> > > We also need to address another elephant in the room... those pesky<br></div><div> > > tuples and their special privileged non-wordy syntax!<br></div><div> > ><br></div><div> > > pair = (,)<br></div><div> > ><br></div><div> > > triple = (,,)<br></div><div> > ><br></div><div> > > quadruple = (,,,)<br></div><div> > ><br></div><div> > > quituple = (,,,,)<br></div><div> > ><br></div><div> > > sextuple = (,,,,,)<br></div><div> > ><br></div><div> > > septuble = (,,,,,,)<br></div><div> > ><br></div><div> > > octuple = (,,,,,,,)<br></div><div> > ><br></div><div> > > If Haskell were invented in this century's EU Haskell source code would<br></div><div> > > be littered with €s instead of $s but then again I wonder why £ wasn't<br></div><div> > > picked. But I digress. We can kill two birds with one stone here:<br></div><div> > ><br></div><div> > > apply = ($)<br></div><div> > ><br></div><div> > > strictApply = ($!)<br></div><div> > ><br></div><div> > > compose = (.)<br></div><div> > ><br></div><div> > ><br></div><div> > > It's fun to imagine how code using those definitions would like! But<br></div><div> > > it's still a -1 for me, sorry!<br></div><div> > ><br></div><div> > ><br></div><div> > ><br></div><div> > ><br></div><div> > > _______________________________________________<br></div><div> > > Libraries mailing list<br></div><div> > > <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br></div><div> > > <a rel="noreferrer" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></div><div> > ><br></div><div> ><br></div><div> > _______________________________________________<br></div><div> > Libraries mailing list<br></div><div> > <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br></div><div> > <a rel="noreferrer" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></div><div> ><br></div><div> ><br></div><div> > _______________________________________________<br></div><div> > Libraries mailing list<br></div><div> > <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br></div><div> > <a rel="noreferrer" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></div><div> _______________________________________________<br></div><div> Libraries mailing list<br></div><div> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br></div><div> <a rel="noreferrer" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></div></blockquote></div></div></div></div></div><div>_______________________________________________<br></div><div>Libraries mailing list<br></div><div><a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br></div><div><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></div><div><br></div></blockquote><div><br></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>