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#t%3AMonoid
that is about a collection (Monoid ([] a)) that has a split operation.
ONE.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
