Re: [Haskell-cafe] Cyclic Inclusions

On 12 Aug 2008, at 16:01, ajb@spamcop.net wrote:

G'day all.

Quoting Thomas Davie :

...

I'm not sure that it does make a lot of sense -- we allow (mutually) recursive functions, even though they come with an efficiency penalty. Why should we not allow (mutually) recursive modules, even though they too come with an efficiency penalty.

The problem is not mutually recursive modules. Plenty of statically typed languages support mutually recursive modules.

The problem is that it's impossible in general to say what the "interface" of a module is by examining the module alone. This is a very unusual property as real-world programming languages go.

You could fix this by, for example, requiring that all symbols exported from a module have an explicit type annotation. Or, if you think that's not lazy enough, it could be an error to use an imported symbol that doesn't have an explicit type annotation. You could even formalise .hi-boot files if you were truly desperate.

If the Haskell spec requires that multiple modules be analysed simultaneously (or multiple times to fixpoint), then that's a bug in the spec. Separate compilation is too important.

Why is separate compilation important? I can understand your point about a module on it's own not being analyzable, and that that's an odd property -- on the other hand, the rapidly emerging "atomic" unit in Haskell is the package, so I see no reason why modules within one package shouldn't depend on each other. Finally, as chris suggests, if separate compilation is important to you, why not have a flag in ghc -frequire-hi-boot or something? Bob