On Sun, Feb 1, 2015 at 4:39 PM, Iavor Diatchki <iavor.diatchki@gmail.com> wrote:
Hello,

On Sun, Feb 1, 2015 at 12:25 PM, Austin Seipp <austin@well-typed.com> wrote:

  - the 'Monoid' class.  Monoids are a useful abstraction, but encoding them as a Haskell class is very much a compromise (in my mind, anyway).  Keeping them in their own module seems like a good idea.

Monoid in Prelude is a result of the AMP, and that's not going to change without breaking code even more, or introducing orphans. Neither of these are going to happen: BBP has nothing to do with it.
 

Really?  This is not obvious at all.  Is it because of the odd `Applicative` instance for pairs? I am saying 'odd' because there are no similar instances for tuples of higher arity;  there are also no instance for `Monad` for the same type, which makes as much sense, I guess.  Obviously this is just an opinion, but I don't think these instances fit pairs naturally, and make for confusing looking code.

instance Monoid m => Monad ((,) m)

is the "unnamed" writer monad that corresponds to the 

instance Monad ((->) m) 

reader monad.

FWIW- On the Comonad side the roles interchange:

instance Monoid m => Comonad ((->) m)
instance Comonad ((,) m)

Both naturally arise in work on recursion schemes.

The same sort of concern lead to

instance Monad (Either a)

a year or two ago unencumbered by Error.

Of course, I can generally work around all of those, so not a big deal.  However,  it'd be nice if we could come up with a design that, more or less, the whole community thinks is a good one.

I understand why you feel that way, but it's simply impossible to do in any scalable or sensible way in general. Why do we need a unanimous vote here? Or, by this reasoning, when would we *not* need a unanimous vote?

Even 80% in agreement is literally a supermajority beyond what you need in almost any liberal democracy in the world to affect change, for example. If we set our standards that high, it's not only slightly ridiculous, it's tantamount to making sure nothing ever changes.

Pleasing all the people all the time is just never going to be possible.
 
 
Agreed.  The benefit of getting a design that is understood and accepted by most of the community is 1) when we use the language we feel it is awesome, and not an uneasy compromise; 2) when we introduce new folks to Haskell, we can explain and defend the various design decisions, 3) when newcomers look for examples of how to do things, they will look in the standard libraries.   I wouldn't give `Foldable` as an example of how to design a type-class.
 
If we can find a longer term path to get a more minimal Foldable without compromising on performance, I'd love to head towards a more minimal definition. After a year and a half of looking, I'm somewhat cynical about its attainability, and there is a certain appeal to being able to offer folks the escape hatch of not having to take slower implementations than what they know they could have if something else in the class.
  
I'd be much happier with changes that actually improve the overall design even at the price of breaking code.  I feel that the BBP does not improve the overall state of the design, and just reshuffles things a bit which, for me, has no benefit.

The benefit of the new state is that we can point to a very simple guiding principle when figuring out what will conflict with the Prelude:

"The Prelude now causes no import conflicts with any names anywhere in base."

This is a much more desirable and teachable end-state than a version of that statement that has 30+ caveats.

-Edward