
People, Who knows, please, how usable are currently recursive module imports in Haskell, in GHC ? Is it essentially more difficult to `make' and support a project which has 50 modules, and half of all the module pairs import each other? Is recursive import in Haskell-98 ? Thank you in advance for explanation. ----------------- Serge Mechveliani mechvel@botik.ru

Serge D. Mechveliani wrote:
People,
Who knows, please, how usable are currently recursive module imports in Haskell, in GHC ? Is it essentially more difficult to `make' and support a project which has 50 modules, and half of all the module pairs import each other? Is recursive import in Haskell-98 ?
Newtype deriving doesn't work for recursive module imports, so I ended up just merging the two mutually recursive modules in my program into one module. The example was something like: module Control where import {-# SOURCE #-} Manager data Control ... -- functions using ManagerM module Manager where import Control data MState = MState{keyboard:: !(Maybe Control)} newtype ManagerM a = ManagerM (StateT MState IO a) deriving (Monad, MonadIO,MonadState) module Manager where {- hs.boot -} data MState -- newtype decl gives a compiler error (I can't remember what it was) newtype ManagerM a = ManagerM (StateT MState IO a) deriving (Monad, MonadIO,MonadState) So from the above experience I'd recommend not to use recursive modules at all. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

Haskell the language allows arbitrary recursive modules. Implementations differ in how they support this. GHC's module-at-a-time compilation model means that GHC needs an hs-boot file to "get started". The manual tries to explain what you can and can't do. If you follow the rules it works pretty well. We use recursive modules extensively for compiling GHC itself, and it's just fine with 'make'. (ghc -M does the right thing.) The other thing to say is that GHC's story has improved a lot since earlier versions. You now write "hs-boot" files (in source code form) rather than "hi-boot" files (in interface-file syntax). And the hs-boot file is checked when you compile the master .hs file. It's far from perfect, but I think it does the job. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 03 June 2006 08:37 | To: glasgow-haskell-users@haskell.org | Subject: recursive import | | People, | | Who knows, please, how usable are currently recursive module imports | in Haskell, in GHC ? | Is it essentially more difficult to `make' and support a project | which has 50 modules, and half of all the module pairs import each | other? | Is recursive import in Haskell-98 ? | | Thank you in advance for explanation. | | ----------------- | Serge Mechveliani | mechvel@botik.ru | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Serge D. Mechveliani wrote:
Who knows, please, how usable are currently recursive module imports in Haskell, in GHC ?
compiling works fine as SPJ pointed out.
Is it essentially more difficult to `make' and support a project which has 50 modules, and half of all the module pairs import each other?
There's little overhead because of the additional hs-boot files. Do you only have cycles involving 2 modules? If your modules are small enough (below 300 lines) I would try to avoid the recursion. I had problems running haddock over recursive modules. (no idea about cabal)
Is recursive import in Haskell-98 ?
No, but your ghc-options list is not Haskell-98, too. Maybe you want to give hugs a chance? Christian

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, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

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
participants (5)
-
Brian Hulley
-
Christian Maeder
-
Johannes Waldmann
-
Serge D. Mechveliani
-
Simon Peyton-Jones