On Mon, Sep 27, 2004 at 10:46:25AM -0700, Fergus Henderson wrote:
(2) Although most of the mutual recursion occurred only in the intermediate stages of the refactoring, some of the mutual recursion remained at the end of the refactoring, forcing two modules with only the smallest degree of coupling to be combined into a single module.
The two modules in question were (a) the module which defines the calling interface between the Cryptol front-end and the various Cryptol back-ends, and (b) the module which defines the structure which records the settings of command-line options. Here (a) depends on (b) because one of the parameters which is passed to the back-ends is the command-line option settings, and (b) depends on (a) because one of the option settings is the currently selected back-end (represented using an existentially quantified typeclass-constrained type).
As a programmer not necessarily speaking about Haskell, I also find that mutually dependent modules are often natural in practice, and that avoiding them requires excessive and awkward factoring. Eg, a configuration module C and a database module D, in which D depends on C because the configuration contains the database to use, and C depends on D because configuration data (other than which database to use!) can come from the database. I think that on principle, haskell implementors should not doubt that programmers will find good use for mutually recursive modules if they are available in a convenient form. Andrew