Proposal: Add singleton function to Data.List module
Oliver Charles
ollie at ocharles.org.uk
Wed Aug 14 19:34:43 UTC 2019
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 at 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 at 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> 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/20190814/1fedb517/attachment.html>
More information about the Libraries
mailing list