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

On 13 June 2013 05:31, 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.

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". 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. Conrad.