On 15/01/2009, at 23:27, Duncan Coutts wrote:
On Thu, 2009-01-15 at 21:21 +0000, Andrew Coppin wrote:
OK, well then my next question would be "in what say is defining configuration files as a monoid superior to, uh, not defining them as a monoid?" What does it allow you to do that you couldn't otherwise? I'm not seeing any obvious advantage, but you presumably did this for a reason...
[ I know I'm repeating myself from elsewhere in this thread but this is the better question for the answer :-) ]
By making a type an instance of Monoid instead of exporting emptyFoo, joinFoo functions it makes the API clearer because it shows that we are re-using an existing familiar concept rather than inventing a new one. It also means the user already knows that joinFoo must be associative and have unit emptyFoo without having to read the documentation.
Perhaps it's what OO programmers would call a design pattern. Identify a pattern, give it a name and then when the pattern crops up again (and again) then the reader of the code will have an easier time because they are already familiar with that named pattern.
Exactly, documenting knowledge was one of the benefits of design patterns. Monoid looks like the Composite pattern, one of the original GoF patterns. Is Composite is a better name for Monoid? I guess that when the GoF folks were writing the book they had to come up with quite a few names, and some came out better than others. If anything, the Haskell approach is more consistent.