I'm +1 on this.

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.

As far as I can tell, it's consistent, convenient, useful, and obvious. This IMO makes it a good candidate for inclusion.

Matt Parsons


On Mon, Aug 12, 2019 at 11:10 AM Oliver Charles <ollie@ocharles.org.uk> wrote:
On Mon, Aug 12, 2019 at 6:03 PM Herbert Valerio Riedel
<hvriedel@gmail.com> wrote:
>
> > - `(:[])`: Subjectively ugly.
>
> I consider "subjectively ugly" to be a non-technical and thus really
> weak argument to dismiss the list-idiomatic ninja-robot-operator (:[])
> which also happens to be shorter than the proposed alias for it. I for
> one don't see a significant benefit for adding a redundant synonym to
> `Data.List` and are thus -1 on this.

You are of course entitled to see this as a weak argument, but those
of us who are writing Haskell for 8 hours a day do not make all of our
decisions based on purely "technical" arguments. How easy it is for
myself and colleagues to review code is significant.

On the other hand, "the existing alternative happens to be shorter"
*is* a weak argument to me. There is no tax on characters typed, and
IMO we should be evaluating this change on whether or not it
contributes to code clarity, rather than "is long to type". Unless you
consider "singleton" to be so long it further obscures code, but I
have a hard time buying that.

Ollie
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries