Proposal: Add Data.Semigroup to base, as a superclass of Monoid

[Gabriel Gonzalez]

On Jun 12, 2013 6:03 PM, "Conrad Parker" <conrad at metadecks.org> wrote:
>
> On 13 June 2013 05:31, Gabriel Gonzalez <gabriel439 at gmail.com> wrote:
> > Forgot to copy `libraries` on my answer to your question:
> >
> >
> > On Wed, Jun 12, 2013 at 3:28 AM, Herbert Valerio Riedel <hvr at gnu.org>
wrote:
> >>
> >> On 2013-06-12 at 00:04:04 +0200, Gabriel Gonzalez wrote:
> >> > I think types that lack an empty element are a misfeature.
> >>
> >> ...so having a data-type for representing non-empty lists (on which
> >> operation such as head/last/minimum/maximum et. al can be proper
> >> statically guaranteed total functions as opposed to resorting to
> >> 'Maybe'-wrapped results which need to be checked dynamically at
runtime)
> >> is a misfeature?
> >>
> >
> > I phrased that poorly.  Non-empty data types are useful, but having a
> > combining operation on those types of type:
> >
> > A -> A -> A
> >
> > ... is not.
> >
> > The very example you gave (non-empty lists) shows why.  If you combine
two
> > non-empty lists you can actually prove a stronger result, that the
combined
> > list has at least two elements.  However, you lose that information if
you
> > use the `mappend` operation.  I'm not saying that non-empty lists
shouldn't
> > have a combining operation, but rather that `mappend` is not the
appropriate
> > operation for the task.
>
> This is a "perfect world" argument: that there is no point in doing
> small step X because in a perfect world, Haskell would be a different
> language with generalized feature Y which subsumes X.
>
> Here, X is "have semigroup" and Y is "having dependent types".
>

No.  I'm saying that even if we had dependent types this would still be a
bad idea because the type of the result will differ from the input types.

> I think this style of reasoning is counterproductive for the libraries
> list. There are good reasons for being conservative about libraries
> changes, but appeal to a perfect world is not a good reason.
>

Anybody who has used the "Edward platform" knows exactly what I am talking
about where the moment you add Semigroup you also have to add Semigroupoid,
Apply, Bind, all just to preserve this entirely parallel ecosystem of
things that are not empty.  It infects everything downstream of it.

Besides, I'm not saying that you can't define an operator that concatenates
two Nonempty lists and produces a Nonempty list.  You can, but don't put it
in base.  Just because there is a mathematical name for it doesn't mean it
is worth adding to our collective cognitive overhead, otherwise we'd also
have Magmas and Actions, too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130612/eb530f6c/attachment.htm>