On Mon, 6 Sep 2010, Evan Laforge wrote:
I have a few techniques to get out: - Replace Things with ThingIds which have no big dependencies, and can then be looked up in a Map later. This replaces direct access with lookup and thows some extra Maybes in there, which is not very nice. - Cleverly use type variables to try to factor out the problematic type. Then I can stitch the data structure back together at a higher level with a type alias. This is sort of complicated and awkward.
That's what I typically make. It was only once, where I could not easily decide which datatype to make the parameter of the other one.
- Move the declarations that must be moved to the low level module, re-export them from the module that defines their (smart) constructors, and pretend like they belong to that module. This works well when it can work, but makes the code awkward to navigate and doesn't let you hide their implementation unless you give up and move the rest of the code in as well.
I often need Private modules anyway for package-wide definitions. Then I define the type in the Private module and export it only from the corresponding public module. Unfortunately, Haddock does not play nicely with it. I would like to tell Haddock to treat the public module as the one that defines the type.
Is this a problem others have noticed? Any other ideas or solutions?
Unfortunately no more ideas, but you may add more thoughts to http://haskell.org/haskellwiki/Mutually_recursive_modules#Resolve_mutual_recursion _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
