GHC currently exposes a *lot* across module boundaries. It could expose much much less -- at a serious cost to optimisation, but serious improvement in "you can recompile library L and still link it with the unmodified application A".
At the moment you get very little control over this. I'd like to make it much more controllable. There are some design questions about just what to do, and how to expose the new controls; for example it'd be ideal to allow lots of cross-module stuff *within* a package, but then seal it up so that *outside* the package you could see a lot less. The current implementation doesn't make that easy. Meanwhile -fomit-interface-pragmas should work fine even with -O on, and should dramatically trim what shows up in interface files. Did you try that? Simon | -----Original Message----- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim | Chevalier | Sent: 04 September 2008 18:06 | To: [email protected] | Subject: External Core output path | | While I'm trying to integrate some additional tools I wrote into the | ext-core library, I thought I might say a word about why getting GHC | to read Core back in is hard (and I don't think I've mentioned this | before, though I may have forgotten). | | When optimization is turned on, or even when it's not, .hcr files | contain all sorts of references to system-generated names that are | defined in other modules (things like dictionary arguments | ($fwhatever) and definitions created by let-floating (lvlwhatever)). | So if you wanted GHC to read the .hcr files back in, you would have to | have exactly the same set of .hi files for all the libraries as when | you compiled the .hcr file. Furthermore, external tool writers need to | make sure they have .hcr files for all the libraries that were | compiled with exactly the same version of GHC that was used to build | the source files. | | I can think of two possible solutions: | - disable optimization, or at least cross-module inlining, when | generating ext-core (or at least warn that it is likely to cause | problems). But taking advantage of GHC's simplifer is a big reason to | want to use the front-end to dump out Core. | - require input .hcr files to be single, self-contained modules with | no external dependencies except primops. This can be achieved with an | external Core-linking tool (which I've written). | -- But this has the problem that some primops mention types | (specifically Bool, though there may be others) that are | non-primitive; thus if you merge a source module with all the | libraries it depends on, you now have a new renamed Bool type that is | incompatible with the Bool type that the primops depend on. I can | think of solutions for this, all of them ugly. | | Any thoughts? | | Cheers, | Tim | | -- | Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt | "Now I'm trying to get back to what I know that I should be / hoping | to God that I was just a temporary absentee" -- Gerard McHugh | | _______________________________________________ | Cvs-ghc mailing list | [email protected] | http://www.haskell.org/mailman/listinfo/cvs-ghc _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
