[GHC] #10871: Implement "buildable" interface files which can be directly compiled without source

[GHC]

#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