Re: separate compilation [was Re: Global variables?]

Andrew J Bromage
G'day all.
On Wed, Feb 05, 2003 at 08:05:56PM -0600, Jon Cast wrote:
I'm not sure I follow this. If you change the type of a value exported from a given module, that's a public change, no? And if you don't, why should re-compilation be needed?
Consider this:
<< module A where
import B
{- use B.b -}
<< module B (b) where
import C
b = C.c
<< module C (c) where
c :: Int
Changing the type of c requires recompiling module A.
You would expect that changing c's type forces a recompilation of B, since you changed C's public interface. However, this also changes B's public interface even though you did not touch the text of module B. The reason is that B's public interface is partly based on modules which it _privately_ imports, even if it does not re-export any symbols from those modules.
I think I see what you're saying. I still maintain, however, that, since you've changed the type of B.b (admittedly implicitly), and B.b is exported from B, that you've changed B's interface. There is a reason make is designed to re-build B /and/ (potentially) A when C changes, after all.
One fix is to require all exported symbols to have explicit type declarations. Since this is good practice anyway, I would be in favour of making it a language requirement in Haskell 2.
Cheers, Andrew Bromage
Jon Cast

G'day all. On Wed, Feb 05, 2003 at 09:28:05PM -0600, Jon Cast wrote:
I think I see what you're saying. I still maintain, however, that, since you've changed the type of B.b (admittedly implicitly), and B.b is exported from B, that you've changed B's interface.
There is a reason make is designed to re-build B /and/ (potentially) A when C changes, after all.
In principle, it shouldn't. If module D imports module E, changing E's implementation should not force a recompilation of module D (assuming no intermodule optimisation, of course). In GHC terms, D.o should only depend on D.hs and E.hi. However, this isn't my main problem. This is at best a big pain, and at worst a potential waste of an expensive software engineer's time. Software engineers like it when they can predict how long a compilation will take. The unknowns are an acceptible risk when intermodule optimisation is turned on, but if I'm being paid by the hour to hack Haskell code, I want a way to turn that off in order to better schedule my day. I digress. My main problem is that under H98, it's not possible, in general, to determine what the public interface of a module actually _is_ without intermodule analysis. This, IMO, breaks pretty much every sensible meaning that you could assign to the term "separate compilation". Cheers, Andrew Bromage
participants (2)
-
Andrew J Bromage
-
Jon Cast