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

[Edward Kmett]

Honestly the main reason that 'semigroupoids' exist is that DataKinds are
pretty much broken at this point in GHC due to the addition of Any and lack
of eta reduction rules.

While I can define a product semigroupoid a product category is still
beyond GHC and I needed them for something I was working on at the time, so
I just ran with it and defined the rest of the relevant hierarchy to
explore what was possible. ;)

I also realize you were going for hyperbole but Actions would require an
MPTC+FD or type family, both are unlikely for anything under consideration
for inclusion in base. ;)

In a 'perfect language' we might have classes for affine, relevant and/or
linear traversals, and similarly restricted folds, but Haskell is not that
language. I'm not going to sit down and define up to 4 restricted variants
of 'traverse' for every data type I define with no real code-reuse between
them.

My experience with the Apply and Bind (semi-applicative and semi-monad)
classes is that they are very rarely worth their weight. I use them in the
linear package so we can have diagonals of sparse matrices use the
'semi-monad' join for IntMap, etc. but that is pretty much the limit of
their utility, unless you want to introduce non-empty traversals in the
lens sense.

Even if Semigroup was talked into base -- which is sounding rather unlikely
at least in the short term -- I'd still be against bringing
Apply/Semiapplicative and Bind/Semimonad into the mix. They'd require a
much bigger change to user code, including requiring lots of CPP noise for
little benefit.

Interestingly each of the "major" current changes under discussion won't
require CPP for almost all users who want to continue to support older
versions. I'm generally willing to put them all over my own code, but
tastes vary.

Haskell's typeclass system is actually remarkably bad at dealing with
overly fine grained class distinctions, because you get very little
OOP-style code reuse as you move down the hierarchy. This tends to cause me
to err on the side of the pragmatists for core library design while still
trying to rectify the situation in my own libraries.

-Edward


On Wed, Jun 12, 2013 at 9:24 PM, 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.
>
> > 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.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130613/0990df5a/attachment.htm>