Proposal: Add Data.Semigroup to base, as a superclass of Monoid
conrad at metadecks.org
Thu Jun 13 03:03:22 CEST 2013
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.
More information about the Libraries