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?

It's basically write once, so I don't see an increase of maintenance burden in the prelude.

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.

So, to the -1s, did I miss anything else?

On Wed, 14 Aug 2019, 6:37 pm Matt, <parsonsmatt@gmail.com> wrote:

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.

To summarize/quote the issues with `(:[])`:

> You can't even search for it on hoogle: https://hoogle.haskell.org/?hoogle=(%3A%5B%5D)
> Another advantage to having an explicit singleton function is discoverablity.

The discoverability of `(:[])` is bad.

> 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).

`(:[])` is not a common idiom (in the code sample I have; your mileage may vary).

> All alternatives to construct a list "anonymously" are confusing and take time to parse.
> 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.

The operator section is confusing and difficult to parse in this context.

Those are the three main problems that people have with `(:[])`, as far as I can tell.

Matt Parsons

On Wed, Aug 14, 2019 at 11:10 AM Herbert Valerio Riedel <hvriedel@gmail.com> wrote:
> `(:[])` is also unsatisfactory

Which is a purely subjective assessment (and one I clearly disagree with)

> To parse it properly, you need to:
>
> - Know that `:` is only allowed as an operator to prefix data constructors,
> - Know that `[]` are not legal operator characters,
> - Infer that you're intended to insert a space between the `:` and `[]` to get `(: [])`
> - Recognize it as an operator section being used prefix as a normal function

Indeed, in order to parse a legit Haskell term, be it (0(,)), (:[0])
or (:".exe") or (:[]) you need to know the core Haskell98 syntax. I'm
aware that other languages such as Elm or Purescript favor different
ideals and design principles but that's not really a good argument to
make either; each language has its own idioms and point in the design
space.

I'm still waiting for a statement of the technical problem we're
trying to solve here which requires the introduction of a redundant
synonym for a concise facility we already have at our disposal by
virtue of the core Haskell98 syntax. Otherwise I'm afraid we're going
to be stuck in this discussion as everything on the topic has been
said and repeated in one way or another and so far we haven't reached
any consensus.
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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