[Haskell-cafe] mutually recursive modules

Adrian Hey ahey at iee.org
Mon Sep 27 20:43:30 EDT 2004


On Monday 27 Sep 2004 8:27 pm, Andrew Pimlott wrote:
> 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.

This is a subject I'd been meaning to whine about, so now seems like
a good time for a "me too" post.

I agree with Henning,Fergus,Andrew. It's annoying when what should be a fairly
straight forward exercise in adding a new function to a module turns out
to far less straight forward because you've introduced circular dependency,
forcing you to either refactor modules which have become "old and familiar
friends" (you know where everything is) for no good reason or start mucking
about with hiboot files.

I don't agree with the view that mutual recursion between modules is
symptomatic of a poor design which badly needs refactoring anyway.
On the contrary, I think perfectly natural and useful for modules
which are part of the same package. If anything this problem _makes_
me produce a poor design by putting some functions in the "wrong"
module.

OK, it doesn't really make me do this. There are alternatives, but I
suspect that in reality most programmers will take the path of least
resistance (certainly I will, given the opportunity :-)

Regards
--
Adrian Hey



More information about the Haskell-Cafe mailing list