Proposal: Add singleton function to Data.List module

[Matt]

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 at ocharles.org.uk>
wrote:

> On Mon, Aug 12, 2019 at 6:03 PM Herbert Valerio Riedel
> <hvriedel at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190812/0d9d00e6/attachment.html>