Re: [Haskell-cafe] For class Monoid; better names than mempty & mappend might have been: mid (mident) & mbinop

So is the change taking effect?

...

We were approaching consensus for the addition of of: infixr 6 <>

...

(<>) :: Monoid m => m -> m -> m (<>) = mappend and a matching change for (<+>) in the pretty package.

...

It was also suggested to make (<>) a method of Monoid and insert the following default definitions: (<>) = mappend mappend = (<>)

And how about the following: (<<>>) = mconcat mconcat = (<<>>)

And "mempty" could be "id".

The problems with this are: - mconcat is not a binary operator, so using <<>> would bring little advantage. You'd always have to use it in its bracketed form, for example. - Changing mempty to id could break a lot of existing code (e.g. due to typeclass ambiguity). This is the main reason. It's also not clear to me that this is a better name (it's just shorter). The current naming of Monoid methods is modelled after list operations, because list is a (the?) free monoid. However, in many cases "zero" or "one" would be an equally good name. I think (<>) is fairly uncontroversial because: 1. It's short 2. It's abstract. i.e., no intended pronunciation and it looks like LaTeX's \diamond operator 3. Changing it would be compatible with most existing libraries. For this reason, I think a larger change would have to come with a larger library re-organization. Johan Tibell suggested something like that a while ago: instead of lots of little cuts (backwards incompatible changes), a working group of activists should redesign a whole new (incompatible) alternative set of core libraries.

On Sun, Jul 24, 2011 at 11:39 AM, Thomas Schilling wrote:

...

Yes, this has sort-of been agreed upon in a GHC ticket about a year ago: http://hackage.haskell.org/trac/ghc/ticket/3339

I had a patch in Darcs, but then came the switch to Git.  I ported it to Git, but didn't iron out all the issues.  That was quite a while ago so it's currently a bit bitrotten.  I don't think it's enough time to get it into 7.2, but since that's largely an unstable release, it wouldn't hurt until 7.4.  I'll probably work on it at CamHac in a few weeks.

-- -- Regards, KC

-- Push the envelope. Watch it bend.