<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 21 Apr 2020 at 11:38, Ömer Sinan Ağacan <<a href="mailto:omeragacan@gmail.com" target="_blank">omeragacan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
I'm currently reading the "recompilation avoidance" wiki page [1], and I have a<br>
few questions about the current design.<br>
<br>
The wiki page says (in the paragraph "Suppose the change to D ...") if a module<br>
B re-exports x from module D, changing x in D does not cause any changes in B's<br>
interface.<br>
<br>
I'm wondering why this is the case. To me this doesn't make sense. Anything that<br>
can potentially effect users of B should be a part of B's interface. This<br>
includes re-exports. I don't understand why there is a difference between normal<br>
exports and re-exports. As far as users of the module concerned there's no<br>
difference. So I'd expect any changes in re-exports to make a difference in B's<br>
interface.<br></blockquote><div><br></div><div>Yes, that's already the case. Under "Deciding whether to recompile", we say:</div><div><br></div><div>* If anything else has changed in a way that would affect the results
of compiling this module, we must recompile.</div><div><br></div><div>so that's the basic requirement.</div><div><br></div><div>We don't want to include the *definitions* of things that are re-exported, because that would bloat interface files a lot. Consider that an interface would have to contain the unfoldings for every exported identifier, and the unfoldings of anything referred to by those unfoldings, and so on. Imagine the size of Prelude.hi! (historical note: it did work this way a long time ago, I think GHC 2.x was when it changed)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The wiki page says (in "Why not do (1)", where (1) refers to making D.x part of<br>
B's interface) </blockquote><div><br></div><div>here (1) refers to</div><div><br></div><div>1. arrange that make knows about the dependency of A on D.</div><div><br></div><div>which is not the same as making D.x part of B's interface.</div><div><br></div><div>This section of the wiki page is about "make", incidentally.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">that this is because sometimes changes in D.x should not cause<br>
recompiling B's users. I don't understand why (1) would cause this problem. If<br>
we make x a part of B, as if it's defined in B, similar to how we can avoid<br>
recompilation of users of B when a definition of B changes but the interface is<br>
the same, we could avoid recompiling users when D.x changes.<br>
<br>
For example,<br>
<br>
    -- B.hs<br>
    module B where<br>
<br>
    b = 123123<br>
<br>
    -- Main.hs<br>
    import B<br>
<br>
    main = print b<br>
<br>
<br>
    $ ghc-stage1 Main.hs<br>
    [1 of 2] Compiling B                ( B.hs, B.o )<br>
    [2 of 2] Compiling Main             ( Main.hs, Main.o )<br>
    Linking Main ...<br>
<br>
Now if I update B and recompile I'll only link Main, won't recompile it:<br>
<br>
    -- B.hs<br>
    module B where<br>
<br>
    b = 123123 + 12308<br>
<br>
    $ ghc-stage1 Main.hs<br>
    [1 of 2] Compiling B                ( B.hs, B.o )<br>
    Linking Main ...<br>
<br>
Now suppose B.b was a re-export from D. I don't understand why changing it in D<br>
would cause recompiling Main if we make b a part of B's interface. I think what<br>
would happen is: because D's interface hash won't change we won't recompile B.<br>
No problems at all.<br></blockquote><div><br></div><div>I think this all stems from the confusion above.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Finally, I'm a bit confused about this part<br>
<br>
> To ensure that A is recompiled, we therefore have two options:<br>
> ...<br>
> (2) arrange to touch B.hi and C.hi even if they haven't changed.<br>
<br>
I don't understand how touching is relevant, as far as I understand touching<br>
can't force recompilation. Example:<br>
<br>
    $ ghc-stage1 Main.hs<br>
    [1 of 3] Compiling A                ( A.hs, A.o )<br>
    [2 of 3] Compiling B                ( B.hs, B.o )<br>
    [3 of 3] Compiling Main             ( Main.hs, Main.o )<br>
    Linking Main ...<br>
    $ touch A.hi<br>
    $ ghc-stage1 Main.hs<br>
    $ touch B.hi<br>
    $ ghc-stage1 Main.hs<br>
<br>
Am I missing anything?<br></blockquote><div><br></div><div>Touching is relevant to "make" only, not ghc --make.  Under "
Why do we need recompilation avoidance?" there are two sections: "GHCi and --make" and "make", but the formatting doesn't make the structure very clear here. Perhaps this got worse when we migrated to gitlab?. Maybe adding an outline would help make the structure clearer?</div><div><br></div><div>Cheers</div><div>Simon<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
<br>
Ömer<br>
<br>
[1]: <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/recompilation-avoidance" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/recompilation-avoidance</a><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>