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

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 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries