Proposal: Add singleton function to Data.List module

[Keith]

For what it's worth, when starting out I found the disconnect between list sugar and list constructor/destructors extremely confusing.
   In retrospect it seems pretty silly, but I could not figure out how lists were consumed as (x : xs) but often produced with [x, x1, ...]. Mistakes like [x, xs] were common.
   When I finally realized that I could construct lists with the list constuctors, I started using them exclusively.

Simplcity and straightforwardness help understanding. It was much easier for me to understand a singleton list as (x : []) than [x]. Having to deal with '(singleton x)' (at the time not knowing the definition of 'singleton') would have been another layer of confusion.

I get that 'singleton' is library design, since in shows up in Map, Array, Set, etc. But for me trying to use lists, it would have only been useful if I defined it myself as a way to learn that constuctors are fuctions, and that 'singleton' means 'single'.

On August 23, 2019 7:56:41 AM UTC, Sven Panne <svenpanne at gmail.com> wrote:
>Am Do., 22. Aug. 2019 um 19:11 Uhr schrieb Kris Nuttycombe <
>kris.nuttycombe at gmail.com>:
>
>> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne <svenpanne at gmail.com>
>wrote:
>>
>>>  I think there's a significant difference between "little helper"
>and
>>> "the monomorphic function that is used to implement `pure`" - with a
>>> slightly different framing, we might be able to come to an agreement
>that
>>> both the monomorphic an polymorphic versions of this function are
>useful in
>>> different contexts. [...]
>>>
>>
>I think we can agree that we disagree here. ;-) My brain is too small
>to
>remember the names of myriads of trivial helpers, so I very much prefer
>general, orthogonal things. In our case: If we have a general,
>polymorphic
>function (often from a type class), just use that. If for some reason
>(rarely!) I want a more monomorphic function, I can just add a plain
>old
>type signature somewhere (no need for funky language extensions like
>type
>applications). This radically reduces the number of things one has to
>remember. In our case: Know type classes + know a way to make things
>more
>monomorphic.
>
>
>> My guiding principle for API design is that one should always expose
>the
>> fundamental building blocks as a low-level API, and then provide a
>smaller
>> interface for the common use cases. Typeclass instances are no
>different -
>> they are the general interface that allows us to invoke what is
>ultimately
>> a monomorphic, low-level building block function in a polymorphic
>context.
>>
>
>This is exactly the opposite API design principle I have: Do not expose
>the
>monomorphic functions if they are already in a type class. You can
>easily
>reconstruct them as a library user via type signtures if this is really
>needed (still haven't seen many convincing examples of that), but you
>can'
>do it the other way round. Less things exposed, no generality/use cases
>lost => easier to remember.
>
>The thing we can probably agree on: API design is hard and it's not an
>exact science, more a kind of art which is assessed in a subjective
>way...
>:-)
>
>>

Keith
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190828/2f935e77/attachment.html>