[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?
Bob
More information about the Haskell-Cafe
mailing list