Proposal: Add singleton function to Data.List module

[Kris Nuttycombe]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190822/4e664f8a/attachment.html>