Thomas DuBuisson wrote:
How does forcing them to learn proposed terminology such as `Appendable' help here? Learners of Haskell do still need to learn what the new word means.
The contention is that 'Appendable' is an intuitive naming that people will already have a rudimentary grasp of. This as opposed to Monoid, which absolutely requires looking up for the average coder.
Intuition tells me: * 'Appendable' add an element to the back of a (finite) linear collection. * There is a 'Prependable' somewhere that add the element to the front. * There is an inverse 'pop' or 'deque' operation nearby. Absolutely none of those things are true. Let's try for 'Mergeable' * mconcat joins two collections, not a collection and an element. * Is should be a split operation. The above is true for the list instance, but false in general. Look at the instances already given that violate the "collection" idea:
Monoid Any Monoid All Monoid (Last a) Monoid (First a) Num a => Monoid (Product a) Num a => Monoid (Sum a)
And I don't even see an (Ord a)=>(Max a) or a Min instance. So the original article, which coined 'Appendable', did so without much thought in the middle of a long post. But it does show the thinking was about collections and there is one ONE instance of Monoid at http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html#... that is about a collection (Monoid ([] a)) that has a split operation. ONE.