<div dir="auto">I'd also be interested in a kind of "reverse" argument - *if* we had this added, what are the costs? There are arguments of "no, pure/robot ninja is enough" - fine, we're not taking those away so you aren't required to use singleton But what is the *downside* of having singleton?<div dir="auto"><br></div><div dir="auto">It's basically write once, so I don't see an increase of maintenance burden in the prelude.<div dir="auto"><br></div><div dir="auto">Of course, if people start to use it and you don't, there is a bit of conflict when it comes to reading others code. It's a slightly longer name, but the name itself is pretty clear. Even if you don't have it fully qualified, it's clear that it constructs a single element of something - the only syntax with potentially more information is the robot ninja operator (in the absence of overloaded lists), which makes it unambiguously about lists. So I think for people comfortable with pure/robot ninja, they would also be able to understand code using singleton. OTOH, the opposite doesn't seem to follow.<div dir="auto"><br></div><div dir="auto">So, to the -1s, did I miss anything else?</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 14 Aug 2019, 6:37 pm Matt, <<a href="mailto:parsonsmatt@gmail.com">parsonsmatt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>There have been 19 votes cast so far. We have twelve +1 votes. Of the -1 votes, three are because "`pure` is fine" and four are because "`(:[])` is fine." I summarized the issue with `pure` in my previous email, and there hasn't been any response or comment on the issues raised.<br></div><div><br></div><div>To summarize/quote the issues with `(:[])`:</div><div><br></div><div>> You can't even search for it on hoogle: <a href="https://hoogle.haskell.org/?hoogle=(%3A%5B%5D)" target="_blank" rel="noreferrer">https://hoogle.haskell.org/?hoogle=(%3A%5B%5D)</a></div><div>> Another advantage to having an explicit singleton function is discoverablity.</div><div><br></div><div>The discoverability of `(:[])` is bad.</div><div><br></div><div>> Is `(:[])` a core idiom? I never see it in work code and I've never seen it in Hackage. To check, I grepped my software directory which has all my Haskell code, and got 122 matches of (:[]) over 1,768,231 loc (as given by wc -l **/*.hs).</div><div><br></div><div>`(:[])` is not a common idiom (in the code sample I have; your mileage may vary).</div><div><br></div><div>> All alternatives to construct a list "anonymously" are confusing and take time to parse.</div><div>> The `(:[])` operator takes me a decent amount longer to parse and recognize, and I have seen intermediate-level Haskellers trip up over unspaced operators like this in several contexts.</div><div><br></div><div>The operator section is confusing and difficult to parse in this context.</div><div><br></div><div>Those are the three main problems that people have with `(:[])`, as far as I can tell.</div><div><br></div><div><div dir="ltr" class="m_138684372066357628gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Matt Parsons</div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 14, 2019 at 11:10 AM Herbert Valerio Riedel <<a href="mailto:hvriedel@gmail.com" target="_blank" rel="noreferrer">hvriedel@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">> `(:[])` is also unsatisfactory<br>
<br>
Which is a purely subjective assessment (and one I clearly disagree with)<br>
<br>
> To parse it properly, you need to:<br>
><br>
> - Know that `:` is only allowed as an operator to prefix data constructors,<br>
> - Know that `[]` are not legal operator characters,<br>
> - Infer that you're intended to insert a space between the `:` and `[]` to get `(: [])`<br>
> - Recognize it as an operator section being used prefix as a normal function<br>
<br>
Indeed, in order to parse a legit Haskell term, be it (0(,)), (:[0])<br>
or (:".exe") or (:[]) you need to know the core Haskell98 syntax. I'm<br>
aware that other languages such as Elm or Purescript favor different<br>
ideals and design principles but that's not really a good argument to<br>
make either; each language has its own idioms and point in the design<br>
space.<br>
<br>
I'm still waiting for a statement of the technical problem we're<br>
trying to solve here which requires the introduction of a redundant<br>
synonym for a concise facility we already have at our disposal by<br>
virtue of the core Haskell98 syntax. Otherwise I'm afraid we're going<br>
to be stuck in this discussion as everything on the topic has been<br>
said and repeated in one way or another and so far we haven't reached<br>
any consensus.<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">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>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">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>