External Core output path
catamorphism at gmail.com
Tue Sep 9 13:14:43 EDT 2008
On Tue, Sep 9, 2008 at 9:00 AM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:
> But the point is that GHC knows *nothing* about (+) except its type and the inlining exposed by GHC.Base.hi. If you changed the definition of (+) at Int, and recompiled GHC.Base.hi, then any ExtCore that had inlined (+) would be wrong -- and might contain references to things that no longer exist.
> To put it another way, exactly which cross-module inlinings would out nuke, and which would you keep? Are some "trusted" or "stable"? The only simple thing is all or nothing.
Well, one solution, which is not simple but not as complicated as it
could be, is (just for ExtCore) to inline only names that appear in
the original source module's export list, under the rationale that
these are less likely to change than system-generated names. But I
agree that the only really simple thing is all or nothing. Perhaps
reevaluating when more people are using ExtCore and we know how they
are using it would be the best course of action. (My own solution is
to merge all modules into a single module before running my external
tools on it, which isn't perfect either, but seems good enough for
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
Just enough: Obama/Biden '08.
More information about the Cvs-ghc