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

[Conrad Parker]

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

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.