<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Hilariously, I just saw this article on my feed which sheepishly admits that it's example of "singleton" isn't actually a thing in Data.List: <a href="https://typeclasses.com/featured/singleton" style="font-family:Arial,Helvetica,sans-serif">https://typeclasses.com/featured/singleton</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 22, 2019 at 8:11 AM Elliot Cameron <<a href="mailto:eacameron@gmail.com">eacameron@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="auto">We also use the money face regularly in our code bases, but I think it's only because the singleton function for lists is not already defined. Every time I see/use it I wince a little.<div dir="auto"><br></div><div dir="auto">Some devs I know will go to lengths to avoid an extra import line. So you often see 'maybe x id' instead of 'fromMaybe x' and 'flip traverse' instead of 'for'.<div dir="auto"><br></div><div dir="auto">No other containers are in Prelude and must have their APIs imported qualified. So they don't suffer from this bias against imports.<br></div><div dir="auto"><br></div><div dir="auto">In any code base the defines it's own idioms, like singleton on lists, you have to imagine that what's obviously on Hackage and what is proprietary will not get the same level of commitment.</div><div dir="auto"><br></div><div dir="auto">P.S. Based on arguments against non-fundanental combinators, I suppose we should remove 'fromMaybe' and 'for' since they are not fundamental?<br></div><div dir="auto"><br></div><div dir="auto">This debate is definitely more ideological than I think anyone quite realized at first. At the very least, having the CLC's position clearly documented might help in the future.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 22, 2019, 7:12 AM Malcolm Wallace via Libraries <<a href="mailto:libraries@haskell.org" target="_blank">libraries@haskell.org</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">I have some data to contribute, from our proprietary codebase of some 4MLoC.  We are perhaps unusual in having the singleton function on lists already for 10 years, so it is easy to do a comparison of the frequency of use.<br>
<br>
The robot monkey (:[]) has 378 uses.<br>
Monkey with a space (: []) has 36 uses.<br>
The list singleton function has 18 uses.<br>
<br>
We also have many other singleton functions at more than 20 different types (vector, tuple, map, set, interval, relation, dict, expression, etc), totalling 1893 uses, so the concept/vocabulary is pretty well-known.<br>
<br>
In addition, I counted the number of direct constructions of lists that use :[] unparenthesised, i.e like x:y:[], and there are 489.<br>
<br>
I find it interesting that given the choice of “singleton” vs direct construction or a partially applied operator, our devs seem to prefer the brevity and naturality of the colon.<br>
<br>
Regards,<br>
    Malcolm<br>
<br>
> On 21 Aug 2019, at 06:31, George Wilson <george@wils.online> wrote:<br>
> <br>
> 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 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" rel="noreferrer" 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 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 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 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 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 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 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 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" rel="noreferrer" 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" rel="noreferrer" target="_blank">ollie@ocharles.org.uk</a> <mailto:<a href="mailto:ollie@ocharles.org.uk" rel="noreferrer" 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" rel="noreferrer" target="_blank">helmut.schmidt.4711@gmail.com</a><br>
>>>    <mailto:<a href="mailto:helmut.schmidt.4711@gmail.com" rel="noreferrer" 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" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer 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" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer 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" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer 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" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer 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" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div>