The great "that's why" is as follows: when you have an abstraction, then it is sufficient to hold the abstraction in mind instead of the whole concrete implementation. That's the whole purpose of abstraction, after all, be it maths or programming.
Let me illustrate this. Suppose you are developing a library that, for instance, has a notion of "settings" and is able to combine two "settings" with several strategies for resolving conflicts between settings with duplicate keys: take the first setting, the second, none, or make a setting with multiple values. For example, an alternative GetOpt. Suppose you don't know what a monoid is and don't even know that such an abstraction exists. Now, when you're reasoning about the library, you have to think "If I combine 3 settings, should the order of combination matter? Hmm, would be nice if it didn't. Also, what should I return if someone queries for a non-existent key in the settings? Should I return an empty list, or a Nothing, or throw an error, or what? Do empty settings make sense?" etc. If you're smart and lucky, you will most probably get most things right and inconsciously create a settings monoid. Now, if you know what a monoid is, you immediately recognize that your settings should be a monoid by nature, and now you have absolutely no doubt that you should make the combining operation associative and provide a unit; and you use this monoid abstraction all the time you are designing this library. Now, you don't think about whether you should throw an error or return a Nothing for an empty key; but instead you think about which result would behave like a unit for the monoid, being motivated by mathematical principles rather than pure intuition. You end up designing a mathematically sound library whose principles make sence and has no design flaws, at least in the mathematically sound part, even if you never actually use the word "monoid" in the documentation. Also, read this post by sigfpe that motivated me to learn abstract algebra in depth (I am yet in the beginning, however), and, overall, this is a breathtaking post: http://sigfpe.blogspot.com/2008/11/approach-to-algorithm-parallelisation.html - this is where I started to appreciate the power of mathematical abstractions even more. 2009/1/17 david48 <dav.vire+hask...@gmail.com>: > All of this is still lacking the great why : why/how an abstraction so > generic can be useful. > I'm starting to believe that the only reason to make a datatype an > instance of Monoid is... why not ! since it's not hard to find an > associative operation and a neutral element. > -- Eugene Kirpichov _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe