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 _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
