On Wed, Jul 1, 2009 at 10:11 PM, David Menendez<d...@zednenem.com> wrote: > In Wed, Jul 1, 2009 at 3:38 PM, Thomas Schilling<nomin...@googlemail.com> > wrote: >> 2009/7/1 David Leimbach <leim...@gmail.com> >>> 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 <d...@zednenem.com> > <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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe