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

[John Lato]

On Thu, Jun 13, 2013 at 9:24 AM, Gabriel Gonzalez <gabriel439 at gmail.com>wrote:

>
> 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.
>
This seems an arbitrary line, you could similarly say that we should remove
(:), because by using cons you can prove a stronger result (the resulting
list has 1 more element than the input), but that information is lost when
using lists.

> > 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.
>
The only reason it infects everything downstream is because it's broken in
base.  If Monoid depended on Semigroup (which is strictly more general),
then working around it in libraries would be much easier.

You can see this with other classes too.  If Functor/Monad were generalized
to work with indexed types, we wouldn't need to use NoImplicitPrelude and
custom classes to make Set a Monad.  If Functor were generalized to work
with arbitrary categories, then you could use the standard Functor instead
of building up a parallel ecosystem around CFunctor.  et cetera.

Of course we need to draw a line somewhere.  Personally I've found
semigroups to be useful, and with 72 direct dependencies (including
yesod-platform) others have too.  There are probably many other cases where
people have made classes for semigroups for various reasons.  I'd be in
favor of making Semigroup a Monoid superclass if it doing so were
relatively unintrusive.  Since that's not currently the case (as Edward
pointed out), I don't think we should proceed at this time.  But that's
purely for engineering reasons, not because semigroups are not useful
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130613/558dd54c/attachment-0001.htm>