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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
