#10871: Implement "buildable" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description:
A fat interface file is like a normal hi file, but with extra information so that GHC can *recompile* the associated module without having to parse, rename and typecheck the source code again. The proposed command- line interface is something like (subject to bikeshedding):
{{{ ghc -c A.hs -fno-code -fwrite-buildable-interface # produces a .hi-build file, then ghc -c A.hi-build # completes building, as if ghc -c A.hs had been called }}}
The primary motivation for this is to support partially compiling indefinite packages, which cannot be compiled to object code due to the fact that some of the dependencies haven't been provided yet. However, there are some other cases where this might be useful:
1. Supercompilation requires having the source of all bindings, buildable interfaces can make this information available, even beyond what storing inlinings might provide 2. A buildable interface file can be used to build variants of a source, e.g. profiling and optimization, even "on the fly" by GHC if necessary. 3. GHCi can take advantage of information from buildable interface files to give more detailed information about otherwise "compiled" modules
And maybe more we haven't thought of yet.
Note: we DO run the desugarer before we write out the buildable interface (so we are essentially serializing a `ModGuts`, not a `TcGblEnv`). This does mean that you can't rebuild a buildable interface with hpc (that's done during desugaring) but that seems like a small price to pay.
New description: A fat interface file is like a normal hi file, but with extra information so that GHC can *recompile* the associated module without having to parse, rename and typecheck the source code again. The proposed command-line interface is something like (subject to bikeshedding): {{{ ghc -c A.hs -fno-code -fwrite-buildable-interface # produces a .hi-build file, then ghc -c A.hi-build # completes building, as if ghc -c A.hs had been called }}} The primary motivation for this is to support partially compiling indefinite packages, which cannot be compiled to object code due to the fact that some of the dependencies haven't been provided yet. However, there are some other cases where this might be useful: 1. Supercompilation requires having the source of all bindings, buildable interfaces can make this information available, even beyond what storing inlinings might provide 2. A buildable interface file can be used to build variants of a source, e.g. profiling and optimization, even "on the fly" by GHC if necessary. 3. GHCi can take advantage of information from buildable interface files to give more detailed information about otherwise "compiled" modules And maybe more we haven't thought of yet. Note: we DO run the desugarer before we write out the buildable interface (so we are essentially serializing a `ModGuts`, not a `TcGblEnv`). This does mean that you can't rebuild a buildable interface with hpc (that's done during desugaring) but that seems like a small price to pay. Question: should we tidy the Core bindings before serializing them out? This is only relevant for determining if `A.hi` files need to be rebuilt if `A.hi-build` changes: if we can avoid needless churn on `A.hi-build`, some `A.hi` files may not need to be rebuilt. However, we'd have to be pretty bang-on certain that the extra tidying phase wouldn't cause change in how we end up compiling things, which is unclear because tidying will drop things that might have been profitable during simplification, but are no longer profitable now. So the answer is probably no. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10871#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler