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

Thomas Schilling nominolo at googlemail.com
Sun Jul 24 22:29:21 CEST 2011


> 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
> <nominolo at googlemail.com> 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.



More information about the Haskell-Cafe mailing list