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

[GHC]

#10871: Implement "fat" 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 Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by ezyang):

 Let's think about it from a user perspective. Right now, if I want to
 compile a simple Haskell file, I don't need to futz around with Cabal: I
 can just ask GHC to build it for me `ghc --make A.hs`. So we want a
 similar experience with Backpack: if someone writes a simple Backpack
 file, they should be able to build it with `ghc --backpack p.bkp`, without
 futzing around with Cabal.

 This is MUCH more important for Backpack programming "in the small" (ala
 ML functors and C++ templates) rather than Backpack programming "in the
 large" (ala replacing package dependencies). I think it's important that
 we get a story that works well for both cases; even though the Backpack
 design is highly oriented towards large-scale modularity, it is much
 easier to get users using the small-scale features first. (Plus, there's
 interesting stuff to be done with alternate syntax building on Backpack
 but better suited for small-scale modularity.) But we can't ask them to
 use Cabal for that!

 Re (2), how can you let cabal-install work without knowing about Backpack?
 If it doesn't know about Backpack units, then it can only operate as it
 does now: building a graph of packages (packages that use Backpack are
 still obligated to state, in a build-depends, what external packages they
 use). So when we say "cabal install A B", we mean, "install package A" and
 "install package B". What does it mean to install an indefinite package?
 Typecheck it and install the fat interface files (so we can typecheck
 against it). What does it mean to install a package which instantiates an
 indefinite package? Compile it, and also compile anything that it
 instantiates. With fat interfaces, GHC can manage compiling the
 instantiated units, since it can just resume that compilation!

 How about installing the resutls? If Backpack were generative, every
 package which instantiates indefinite units would just get their own
 private copy of any other units it instantiated, and together they would
 constitute the package you would install. Fat interface files work
 perfectly for this case. But since Backpack is applicative, we also want
 identical instantiated units to be shared. Here is where you might object,
 since I am cheating here, but what seems easiest is to have GHC and Cabal
 (but not cabal-install) conspire to deduplicate instantiated units "behind
 the scenes".

 You might say that this will work really poorly for traditional
 distribution package managers. If C and D both instantiate A(B), where do
 the "install files" for A(B) live? The only reasonable place to put them
 in a distro is in their own package, implying that a distro packages you'd
 create for packages that use Backpack would have to know about how
 everything is instantiated. But traditional distribution package managers
 (e.g. deb, rpm) already can't deal with having both foo-0.1 and foo-0.2
 installed at the same time. So it's no surprise that they'll have some
 trouble dealing with Backpack, which subsumes this mode of use. And if you
 do have a distro that can deal with it (e.g. Nix), you can either bundle
 private copies of the instantiated copies (and rely on GHC's linker to
 deduplicate them later, following on how C++ compilers handle this), or
 you can do as you suggest and run enough of Backpack to figure out how
 things are instantiated, and then make a build task for each instantiated
 unit. I think you are right that we will want to build this eventually;
 but I don't want it to be the default, and I want something simpler for
 casual use.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10871#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler