Edits after class look like this.
Questions, comments, complaints?
A structure is record of type definitions and value definitions. A signature describes structures that share the same interface. A functor is a function that given a structure (that satisfies some signature) produces a new structure (that satisfies some signature).
This is one system for creating modular software. The classes, interfaces, etc. found in many object-oriented languages are another. Typeclasses in Haskell are another.
The special Elm type variables number, comparable, and appendable described in IntroML comprise limited, built-in support for a few signatures or interfaces or typeclasses.
Elm places a particular emphasis on accessibility and learnability. It is debatable when along this learning curve such mechanisms for large-scale code organization are needed. Elm is evolving and has not yet provided (and thus committed to) any one of these mechanisms: ML module systems, Haskell typeclasses, and OO class systems are all quite different, and each of these approach come in many different flavors. It's not clear which is best for Elm's purpose without more examples, experience, and research.
Monads don't necessarily rely on typeclasses, or any of the other mechanisms above. Those andThen functions are monadic interfaces. Elm just doesn't support abstracting over operations like andThen (which would require a Monad signature or typeclass or interface) and corresponding syntactic sugar like do-notation.
BugHunt.elmBreak out, and come back as soon as your group finds you find the bugs!
[answers below]
Bugs: list664, list153, and list553