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

[Ben]

i'm not voting for semigroups, but it seems like there are useful examples of combining datatypes without a unit.  for example, Int under min or max.  you might imagine wanting to express finding the smallest or largest element of a collection as a fold that combines Int over min and max.  to be fair, one can always add unit element to a semigroup, in this case +/- infinity, but it seems unnecessary to require it when it is not needed for your computation.

best, b

On Jun 12, 2013, at 2:31 PM, Gabriel Gonzalez 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.
> 
> > They usually end up contaminating everything they touch, which is why
> > semigroups forms an entire parallel ecosystem of its own.
> 
> Can you provide a concrete example showing the kind of problematic
> "contamination" that is caused by semigroup-forming types?
> 
> 
> The non-empty list example shows what I meant.  The moment you start including extra information like non-emptiness you have to re-engineer all downstream operations to preserve that information as faithfully as possible.  Again, there's nothing wrong with that, but it's not deserving of its own type class or a special place in the Prelude.
>  
> cheers,
>   hvr
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries