Perhaps the problem is that you're trying to build a class hierarchy in Haskell, when class hierarchies just don't really work in Haskell.<p>What about a component oriented design? This is the standard architecture for games anyway.<p>An enemy, actually every <i>entity</i>, would just be a map of components, which can be simple algebraic data types.
The actions can be implemented as a system function with pattern matching or guards, like:<p><pre><code> -- The walking system
walk :: Entity -> Entity
walk e = update entity "position" $ walk' (lookup "position" entity)
walk' (x,y) = (x+1,y)
</code></pre>
In reality systems usually work on more than one component, so you'd have to make actions that work on tuples of components, but you'll figure it out :)
The proposed class hierarchy for different types of "game objects" is exactly the type of hierarchy which will bite you in the ass very soon when adding more features, an entity-component-system would be a better solution for this specific problem (composition instead of inheritance). Newbie programmers should never be taught this "animal - cat - dog" nonsense IMHO because this approach of modelling software after real-world objects doesn't work for anything slightly more complex. For instance, what if you have two different enemy types which both need to implement a common feature but differ in others? Please don't say 'multiple inheritance' ;) This doesn't mean that OOP is bad at all IMHO, just that it shouldn't be treated as a holy grail (applies to all design principles), and doesn't mean that you have to go all-functional. All IMHO of course.
These exercises have nothing to do with expression problem.<p>The goal of expression problem is ability to add new cases in type and new operations on type <i>without touching</i> existing code (and without compromising static type safety)