Proposal: Add singleton function to Data.List module

[Tony Morris]

In (my) most to least preferred:

* NonEmpty#singleton
* <doesn't exist at all>
* []#singleton


On Fri, Aug 23, 2019 at 3:12 AM Kris Nuttycombe <kris.nuttycombe at gmail.com>
wrote:

> On Thu, Aug 22, 2019 at 3:58 AM Sven Panne <svenpanne at gmail.com> wrote:
>
>> I think the main problem of this discussion (and other similar threads on
>> this list) is that there is no consensus about how to design an API. IMHO,
>> piling up little helpers just because they came up in a few places is a
>> recipe for horrible, bloated APIs. The questions one should ask are "Does
>> it generalize things?", "Does it make my API more powerful?" (i.e. can I do
>> things I couldn't do before), "Does it remove common pitfalls?" etc.  But
>> this is just my personal view, obviously others seem to disagree.... :-/
>>
>
>  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.
>
>
> https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.Base.html#line-972
>
> We define a monomorphic function for this operation, we just hide it in
> the implementation of the typeclass instance; we do this frequently,
> intentionally making a monomorphic function inaccessible to the user unless
> it's called in a polymorphic context (and, if they want to intentionally
> monomorphise it, require using an extension - type applications - which is
> particularly ugly/inconvenient for operators like `>>=`.) I think this is
> unfortunate as a general design choice; the user of a library should have
> the flexibility to choose, not be forced into one or the other. For [] we
> have the robot monkey operator, and this is an idiom that people can become
> familiar with - but it does not appear natively in any documentation; it is
> a partially applied constructor rather than a top-level function.
>
> 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.
>
> Kris
> _______________________________________________
> 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/20190823/6e9a1267/attachment.html>