If you're learning Haskell, which communicates the idea more clearly:

* Appendable

or

* Monoid

But Appendable is wrong.

merge :: Ord a => [a] -> [a] -> [a]
merge [] ys = ys
merge xs [] = xs
merge (x:xs) (y:ys) | x <= y = x : merge xs (y:ys)
                              | otherwise = y : merge (x:xs) ys

newtype MergeList a = MergeList [a]

instance (Ord a) => Monoid (MergeList a) where
    mempty = MergeList []
    mappend (MergeList xs) (MergeList ys) = MergeList (merge xs ys)

This is a perfectly good monoid -- one I have used -- but in no sense would I call MergeList "appendable".

Also, in what sense is mappend on Endo appending?

I just realized that the name "mappend" sucks :-). (++) would be great!

In any case, to me being a Monoid is about having an associative operator, not about "appending". The only fitting terms I can think of are equally scary ones such as "semigroup".

Which is worse: naming things with scary category names, as in "monad" and "monoid", or naming things with approachable popular names that are wrong (wrt. to their popular usage), as in "class" and "instance".

In the former case, the opinion becomes "Haskell is hard -- what the hell is a monad?"; in the latter it becomes "Haskell sucks -- it's class system is totally stupid" because we are violating people's intuitions, rather than providing them with none whatsoever.

In a lot of cases there is a nice middle ground. Cases where (1) we can find an intuitive word that does not have a popular CS meaning, or (2) where the popular CS meaning is actually correct ("integer"?). But eg. programming with monads changes the way you think; we cannot rewire people's brains just-in-time with a word.

I like the word Monad. It makes people know they have to work hard to understand them.

Luke