<div dir="ltr"><div>I'm +1 on this.</div><div><br></div><div>It's nice to have a relatively consistent naming scheme between container-types - `Data.Set` and `Data.Map` sharing mostly the same API names is really helpful for writing code without having to look up the specifics.  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. Container-specific functions can be really useful to fix an ambiguous type in a long sequence of constrained polymorphic functions (like `length "hello"` becoming ambiguous with `OverloadedStrings`), and I've written `pure @[]` before to provide this disambiguation.</div><div><br></div><div>As far as I can tell, it's consistent, convenient, useful, and obvious. This IMO makes it a good candidate for inclusion.</div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Matt Parsons</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 12, 2019 at 11:10 AM Oliver Charles <<a href="mailto:ollie@ocharles.org.uk">ollie@ocharles.org.uk</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">On Mon, Aug 12, 2019 at 6:03 PM Herbert Valerio Riedel<br>
<<a href="mailto:hvriedel@gmail.com" target="_blank">hvriedel@gmail.com</a>> wrote:<br>
><br>
> > - `(:[])`: Subjectively ugly.<br>
><br>
> I consider "subjectively ugly" to be a non-technical and thus really<br>
> weak argument to dismiss the list-idiomatic ninja-robot-operator (:[])<br>
> which also happens to be shorter than the proposed alias for it. I for<br>
> one don't see a significant benefit for adding a redundant synonym to<br>
> `Data.List` and are thus -1 on this.<br>
<br>
You are of course entitled to see this as a weak argument, but those<br>
of us who are writing Haskell for 8 hours a day do not make all of our<br>
decisions based on purely "technical" arguments. How easy it is for<br>
myself and colleagues to review code is significant.<br>
<br>
On the other hand, "the existing alternative happens to be shorter"<br>
*is* a weak argument to me. There is no tax on characters typed, and<br>
IMO we should be evaluating this change on whether or not it<br>
contributes to code clarity, rather than "is long to type". Unless you<br>
consider "singleton" to be so long it further obscures code, but I<br>
have a hard time buying that.<br>
<br>
Ollie<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>