[Haskell-cafe] Cyclic Inclusions

Thomas Davie tom.davie at gmail.com
Tue Aug 12 10:35:41 EDT 2008

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

> G'day all.
> Quoting Thomas Davie <tom.davie at gmail.com>:
>> 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?


More information about the Haskell-Cafe mailing list