Proposal: Add singleton function to Data.List module

[Zemyla]

Why hasn't anyone noticed that the singleton function for NonEmpty is just
a monkey robot with a mustache? (:|[])

Also, pure works perfectly fine here as well.

On Thu, Aug 22, 2019, 17:52 Tony Morris <tmorris at tmorris.net> wrote:

> 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
>>
> _______________________________________________
> 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/20190822/9307e49e/attachment.html>