On Tue, Jun 06, 2006 at 02:39:00PM +0200, Johannes Waldmann wrote:
As for recursive module imports, could you perhaps show an example where this occurs. I found that in my code, I can re-arrange things so as to remove the cyclic dependency. Best regards,
This is somewhat like this: -------------------------------------------- module DInteger where import Polynomial ... various classes class ... => WithFactorization a where gcD :: ... isPrime :: ... factor :: ... ... instance WithFactorization Integer where gcD = gcd isPrime n = ... complex implementation using instances for Polynomial Integer factor n = ... ... ... various instances for Integer. -------------------------------------------- module Polynomial where import DInteger ... various instances for Polynomial, which use instances for Integer. --------------------------------------------- `Integer' is a basic data used by many "higher level" data. On the other hand, some advanced method implementations for Integer need operating with Polynomials, Matrices, and so on. If I join the above two modules, this will cause joining into one module about all (numerous and large) modules of the project. Of course, one can also avoid import recursion by adding intermediate classes and by copying parts of implementation. But this complicates the global algorithm presentation, and it is better to use recursive import.
From scientific point of view, modules should express the classification of notions (or algorithm parts) by relevance. This often leads to cycles by the operation import.
Also note that the GHC implementation is said to use recursive import. ----------------- Serge Mechveliani mechvel@botik.ru