Forgot to copy `libraries` on my answer to your question:
On Wed, Jun 12, 2013 at 3:28 AM, Herbert Valerio Riedel
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