Re: [Haskell-cafe] Monoid wants a (++) equivalent

On Wed, Jul 1, 2009 at 10:11 PM, David Menendez wrote:

In Wed, Jul 1, 2009 at 3:38 PM, Thomas Schilling wrote:

...

2009/7/1 David Leimbach

...

Just because the compiler can figure out what I mean because it has a great type system, I might not be able to figure out what I mean a year from now if I see ++ everywhere.

...

Yep, had the same experience.  On the one hand, using monoids lets you delay some design decisions for later and lets you reuse more library code.  On the other hand, it sometimes makes it really hard to see what the code is actually doing--especially if you use more than one monoid.

For this reason on of the first advanced features I implemented in the (yet unreleased) scion IDE library allows you to look up the instantiated type of an identifier.  Unfortunately, jumping to the definition (or documentation) of the monoid instance is a bit more difficult.  Haddock should allow documentation on instance declarations...

I disagree. The solution is to not create instances when it isn't obvious what the instance does. That's why we have Sum and Prod in Data.Monoid instead of declaring instances directly for Int.

With Monoid, I'd go further and say that you should not use mempty and mappend unless you are writing polymorphic code. If you are writing to a specific monoid instance, you should use a specific function.

-- Dave Menendez http://www.eyrie.org/~zednenem/ _______________________________________________

I tend to disagree. I think that Haskell has seen a lot of syntax bloat in the interest of monomorphism. We have List.append, Map.union, Set.union, Sequence.><, etc., all with different notation, even though these all denote the same operation: taking two of (whatever) and combining them into one. With mappend, you know exactly what the function is supposed to do: combine two things together, and it doesn't matter what datatypes you're using, because that's always what it means. Alex