[Haskell-cafe] circular imports

corentin.dupont at ext.mpsa.com corentin.dupont at ext.mpsa.com
Tue Sep 7 07:50:56 EDT 2010

I had recently a really hard time splitting up my program into parts!
The natural, business-oriented split up drove me into a deadly circular
I tried to solve it with:
- .hs-boot: It adds a lot of duplicated code and unecessary files, so I
gave up
- type variables: that too complifies the code with no obvious reasons

Finally, i ended up with putting all my types into a file names Types.hs.
It's not very satisfatory, since I like to keep the types next to their
related code and functions (like it is in the libraries).
But I founded this is the way that adds the less burden to the code.


             Mathew de                                                     
             <deteego at gmail.c                                         Pour 
             om>                       Ivan Lazar Miljenovic               
             Envoyé par :              <ivan.miljenovic at gmail.com>         
             haskell-cafe-bou                                           cc 
             nces at haskell.org          haskell <haskell-cafe at haskell.org>  
                                       Re: [Haskell-cafe] circular imports 
             07/09/2010 06:52                                              

I had the same issue zonks ago, and I resorted to using the hs-boot file
method as well (which worked fine)

Which I guess brings me to my second point, is this something that GHC
should do automatically when it sees circular dependencies? When I asked
about it earlier on #haskell, I was told that its better that way because
it discourages making bad design through circular dependencies (yet in my
case and I assume the other cases as well, not using the hs-boot method
would have made the design much worse). Are there any cases in particular
where people would be encouraged to make interface design with
circular dependencies (and that design be deemed as horrible) as opposed to
what seems to be more realistic case where circular dependencies rarely
crop up, and when they do they actually make the design better?

On Tue, Sep 7, 2010 at 1:48 PM, Ivan Lazar Miljenovic <
ivan.miljenovic at gmail.com> wrote:
      On 7 September 2010 03:44, Edward Z. Yang <ezyang at mit.edu> wrote:
      > Excerpts from Evan Laforge's message of Mon Sep 06 13:30:43 -0400
      >> I feel like the circular imports problem is worse in haskell than
      >> other languages.  Maybe because there is a tendency to centralize
      >> state, since you need to define it along with your state monad.
      >> the state monad module must be one of the lower level ones, since
      >> modules that use it must import it.  However, the tendency for
      bits of
      >> typed data to migrate into the state means it's easy for it to
      >> eventually want to import one of its importers.  And the state
      >> module gets larger and larger (the largest modules in my system
      >> those that define state monads: 1186 lines, 706 lines, 1156
      >> lines---the rest tend to be 100--300 lines).
      > I have used hs-boot files to this effect.  I separated data and
      > and typeclasses, which must be in the same module as data or are
      > orphaned, get definitions via a circular import.

      I'm just getting to the point where I have a similar problem.  I was
      thinking about splitting instances off from the classes (and telling
      GHC to not worry about orphaned instances for the instance-only
      modules) but then realised that some instance declarations would be
      circular as well, so I have to either use hs-boot files, define
      everything in one big module and then re-export them in ways that
      sense or define all instances in one big module (at least for those
      types which have circular deps among instances) and re-export

      Ivan Lazar Miljenovic
      Ivan.Miljenovic at gmail.com
      Haskell-Cafe mailing list
      Haskell-Cafe at haskell.org
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org

More information about the Haskell-Cafe mailing list