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,
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