Proposal: Add singleton function to Data.List module

[Scott Marks]

I confess I am a minimalist. Been coding Haskell for a year after a break
(my 1982 dissertation was “Optimization of Functional Programs” so my
interest goes back a ways).  Were I the God of Haskell I would go down the
above-mentioned synonym list and deprecate all the less-general “return”
things.

I confess also that the semantics of “pure” seems in some cases ((,), etc)
to have been chosen for pragmatic reason; inevitably one must choose an
embedding when there is a choice, and “I got there first” can be justified
if it produces lots of elegant simplicity. To my taste it’s too bad that
Collection means “ordered collection” but I imagine that there are more
applications in which deterministic iteration is useful.

All that being said, I vote for singleton as a readable method name for
Collection instances.
To my way of thinking this implies picking a Collection class and moving it
closer to the Root of all Haskell.

On Thu, Aug 15, 2019 at 13:23 Andreas Abel <andreas.abel at ifi.lmu.de> wrote:

> Sven Panne wrote:
>
>  > Code is mainly *read*, not written, so the less you need
>  > to know to read and understand code, the better it is.
>
> Yes, and this is an argument *for* singleton, not against:
>
> 1. singleton is already known to the Haskell reader from the other
> collection types.
>
> 2. singleton is unambiguously invoking the image of creating a singleton
> collection.
>
> In contrast, "pure" invokes the image of creating a effect-free monadic
> computation.  (:[]) invokes the image of a (mechanical) gorilla smiling
> at you. ;-)  All these associations distract from reading the code.  In
> both cases, a mental translation step is needed:
>
> a) In the case of "pure", the conscious intervention that here we are
> not concerned with non-determinism (the list monad), but just creating a
> singleton collection.
>
> b) In the case of "(:[])", the conscious intervention consists of
>     - recognizing the decomposition (: [])
>     - recognizing the operator section
>     - understanding it as "cons something to the empty list"
>     - understanding this as creating a singleton collection.
>
> Both interventions hamper the flow of reading.
>
> Of course, the procedure b) becomes automatic with use.  However, it is
> still a significant barrier to the newcomer.
>
> Cheers,
> Andreas
>
> P.S.: if the gorilla (:[]) is vanishing from the Agda code base, I am
> mostly to be blamed for this.
>
> On 2019-08-14 21:51, Sven Panne wrote:
> > Am Mi., 14. Aug. 2019 um 21:35 Uhr schrieb Oliver Charles
> > <ollie at ocharles.org.uk <mailto:ollie at ocharles.org.uk>>:
> >
> >     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? [...]
> >
> >
> > A similar argument comes up with basically every extension, and it is a
> > very weak one. Code is mainly *read*, not written, so the less you need
> > to know to read and understand code, the better it is. Lots of different
> > ways to do the same thing makes programs harder to understand, and you
> > ultimately end up with Perl. :-}  And if we take this argument
> > seriously, we should probably add "doubleton" (synonym for "replicate
> > 2"), "tripleton" (synonym for "replicate 3"), etc., too.  Hey, you don't
> > have to use it after all, we're not taking away "replicate"...
> >
> > _______________________________________________
> > 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/20190815/b85f021c/attachment.html>