On 7 September 2010 03:44, Edward Z. Yang wrote:

Excerpts from Evan Laforge's message of Mon Sep 06 13:30:43 -0400 2010:

...

I feel like the circular imports problem is worse in haskell than other languages.  Maybe because there is a tendency to centralize all state, since you need to define it along with your state monad.  But the state monad module must be one of the lower level ones, since all 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 monad module gets larger and larger (the largest modules in my system are 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 functionality, and typeclasses, which must be in the same module as data or are considered 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 make sense or define all instances in one big module (at least for those types which have circular deps among instances) and re-export accordingly. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

I was under the impression that the main reason GHC requires .hs-boot files is that nobody has had the time or inclination to make it resolve circular dependencies automatically, and not an intentional design decision to encourage "good design". On Tue, Sep 7, 2010 at 6:51 AM, Mathew de Detrich wrote:

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@gmail.com> wrote:

...

On 7 September 2010 03:44, Edward Z. Yang wrote:

...

Excerpts from Evan Laforge's message of Mon Sep 06 13:30:43 -0400 2010:

...

I feel like the circular imports problem is worse in haskell than other languages. Maybe because there is a tendency to centralize all state, since you need to define it along with your state monad. But the state monad module must be one of the lower level ones, since all 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 monad module gets larger and larger (the largest modules in my system are 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 functionality, and typeclasses, which must be in the same module as data or are considered 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 make sense or define all instances in one big module (at least for those types which have circular deps among instances) and re-export accordingly.

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 7 September 2010 16:09, Mathew de Detrich wrote:

That definitely makes more sense

Well, the report (section 5.7) says you're allowed to request extra info for mutually recursive modules... -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Thanks for the clarification On 07/09/2010 5:30 PM, "Simon Peyton-Jones" wrote: I was under the impression that the main reason GHC requires .hs-boot files is that nobody has had t... Indeed. I’ve added some notes here http://hackage.haskell.org/trac/ghc/ticket/1409#comment:37 Simon *From:* haskell-cafe-bounces@haskell.org [mailto: haskell-cafe-bounces@haskell.org] *On Behalf Of *Daniel Peebles *Sent:* 07 September 2010 06:06 *To:* Mathew de Detrich *Cc:* Ivan Lazar Miljenovic; haskell *Subject:* Re: [Haskell-cafe] circular imports I was under the impression that the main reason GHC requires .hs-boot files is that nobody has ...

Hello, 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 dependency. 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. Cheers, Corentin Mathew de Detrich Ivan Lazar Miljenovic Envoyé par : haskell-cafe-bou cc nces@haskell.org haskell Objet 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@gmail.com> wrote: On 7 September 2010 03:44, Edward Z. Yang wrote: > Excerpts from Evan Laforge's message of Mon Sep 06 13:30:43 -0400 2010: >> I feel like the circular imports problem is worse in haskell than >> other languages.  Maybe because there is a tendency to centralize all >> state, since you need to define it along with your state monad. But >> the state monad module must be one of the lower level ones, since all >> 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 monad >> module gets larger and larger (the largest modules in my system are >> 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 functionality, > and typeclasses, which must be in the same module as data or are considered > 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 make sense or define all instances in one big module (at least for those types which have circular deps among instances) and re-export accordingly. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

That sort of code (stripped out): In Game.hs: data Game = Game { ... activeRules :: [Rule]} applyTo :: Rule -> Game -> Game applyTo r gs = ... In Rule.hs: data Rule = Cond (Obs) Rule Rule | many others.. deriving (Read, Show, Eq, Typeable) data NamedRule = NamedRule { ..., rule :: Rule } isRuleLegal :: Rule -> NamedRule -> Game -> Bool isRuleLegal = ... In Obs.hs: data Obs a where ProposedBy :: Obs Int -- The player that proposed the tested rule ... evalObs :: Obs -> NamedRule -> Game -> EvalObsType evalObs = ... Corentin Johannes Waldmann haskell-cafe@haskell.org Envoyé par : cc haskell-cafe-bou nces@haskell.org Objet [Haskell-cafe] Re: circular imports 07/09/2010 14:00 writes:

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 dependency.

perhaps you could post your code (enough of it to understand the problem)? J.W. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Henning Thielemann writes:

As I see there is no cycle in the types. How about defining Game, Rule, Obs in private modules, like Private.Game, Private.Rule, Private.Obs, and implementing the functions in public modules like Game, Rule, Obs ?

I guess that conflicts with the advice of putting the functions (behaviour) close to the data that it concerns. But if a function mentions two types (and the types are separate), it requires a decision - in OO as well: you would (arbitrarily) make them a method of one class or the other. J.W.

That sort of code (stripped out):

In Game.hs:

data Game = Game { ... activeRules :: [Rule]}

applyTo :: Rule -> Game -> Game applyTo r gs = ...

Often, it helps to parameterize the types/functions (instead of using recursive modules to hardcode the parameters). Would something like this work for your case (taking the Game module out of the loop)? data Game rule = Game { ... activeRules :: [rule]} applyTo :: rule -> Game rule -> Game rule applyTo r gs = ...

In Rule.hs: .. isRuleLegal :: Rule -> NamedRule -> Game Rule -> Bool isRuleLegal = ...

In Obs.hs:

evalObs :: Obs -> NamedRule -> Game Rule -> EvalObsType evalObs = ...

For the record, I'd like to have recursive modules without having to go outside the language (some standardized notion of Haskell module interfaces would be nicer than implementation-specific boot files). But I'd like to have parameterized modules even more, as that would allow me to avoid many use cases of recursive modules (again, that would seem to require module interfaces). Claus