Proposal: Add a Semigroup-equivalent superclass of Alternative

[Mario Blažević]

     On 04/05/2015 12:13 PM, Edward Kmett wrote:
> There are many points in the design space.
>
> * There is a pure Semigroup1, which acts as an indexed semigroup, 
> without the Applicative superclass, which is the Alt class in the 
> semigroupoids package.

     Yes, I suppose that makes Semigroup1 a wrong name for this 
proposal, but do these points in the design space actually conflict with


> * There is a Alternative minus empty, which you've proposed here.

     I mean, Alternative is already in wide use in parsers. From this 
starting point, AlternativeMinusEmpty would clearly be a useful thing on 
its own: it's an abstraction of irrefutable parsers and generators. If 
we later find a use for the plain Semigroup1 or Functor => Alt, 
backward-compatibility aside, they could just become superclasses of 
AlternativeMinusEmpty. Which would then lead to the problem where

> ...
> Haskell is remarkably bad at dealing with very fine-grained class 
> hierarchies.

     You've blogged about this in

https://www.fpcomplete.com/user/edwardk/editorial/procrustean-mathematics

and I understand your concerns, even if I'm personally rooting for the 
centipedes. I have to say that, both when I read the article, and 
re-reading it again now, I wished for a clearer statement of the 
problem. Is it so fundamental in mathematics, as you seem to imply, that 
no programming language will ever be able to reconcile alternative 
abstractions? Or is it only a problem with Haskell and the proposed 
superclass extensions, as you suggest in

> Even with one of the superclass default proposals, you get no real 
> code reuse for any form of transformer, and the existing default 
> signature mechanism runs "the wrong way" in such a way that it even 
> forces you to put everything in the same module.

     In the latter case, can you point to a design, or a sketch of it, 
that would be better?

>
> With all of that in mind, I'm personally -1 on this addition. I don't 
> think it rises to the level of traction needed to ask everyone 
> everywhere to change all the code that they have ever written that 
> involves MonadPlus, when the design space remains as large as it is.

This proposal wouldn't touch MonadPlus with a ten-foot pole.