dramforever: The point of this post was to show that the free monoid in Haskell is a type that contains infinite values. It is incorrect to use set-theoretic intuition and say that the free monoid only contains finite sequences (at least, if you care about things beyond a “fast and loose” level).

This is the same reason that data types contain infinite values in Haskell. They are still inductive definitions, but the induction is properly understood to be on domains, not sets. The domain structure induces the infinite values, despite induction ‘normally’ only giving you finite values in set theory. The same thing happens for free things.

Olaf: I think most Monoid instances are fine. The thing you usually have to be careful of is not being too lazy. For instance, if you write ‘mappend _ _ = ()’ for the unit monoid, it is wrong, because then ‘mappend mempty undefined = ()’, when it should be undefined. Most definitions can’t get away without looking at the arguments, though, so they don’t have this problem. (Monoid a, Monoid b) => Monoid (a,b) is another case where you’d have to be careful, though.

FM is a monad, and you have the relevant structure correct. It’s also a MonadPlus that does the ‘obvious’ thing.

]]>structure :: Monoid a => FM a -> a;

structure (FM f) = f id

At least struct.embed = id is true. ]]>

toFreeMonoid (repeat 1)

There doesn’t exist a free monoid set containing a string of infinite number of 1’s, therefore either the concept of free monoid must me generalized, or the most fundamental operation of Foldable is not toFreeMonoid

(Correct me if I’m wrong.)

]]>And who cares what an OOP programmer would expect? Aren’t we more concerned with what a functional programmer would expect?

]]>example that I was waiting for: bigger than

the ones I have seen so far, but still digestible. I will take a closer look soon. ]]>