A small complement to my previous post.

From: Nate Nystrom <nystrom@cs.cornell.edu>

> Furthermore, to allow extension, recursion is left open for
> the functions implementing the compiler passes and then closed
> in order to invoke the function on a particular type.  Thus, when a new 
> variant is added, a small amount of code for each open recursive
> function needs to be written to close the recursion with the new type.

This kind of practical problems could be easily solved by syntactic
sugar.
Yet, you can see a direct approach (without sugar) in this code sample
  http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/mixin2.ml.txt
The idea is to use classes like modules with inheritance and
recursion (using lazyness to get a fixpoint). So we get closer to your
approach.
(I've cleaned-up a little, but this code has been at this URL for years.)


Another more general remark, which might seem somehow contradictory,
is that functional programs do not have the same notion of modularity.
In particular, as the typing helps a lot, this is not seen as a
problem to directly modify existing code (which modular extension
prohibits).
So one writes code with the possibility of future modifications in
mind, making it more robust by avoiding ad-hoc defaults. When you have
no default, the type checker can track changes to types, and force you
to modify relevant code.

Jacques Garrigue