[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):

 I think the difference in opinion stems from whether or not it's
 reasonable to ask the user to have built on the non-leaves prior to
 actually building the unit in question. Of course, the only way the user
 is going to do this in practice is with external tooling, e.g. cabal-
 install. But this is true for pre-Backpack packages too; no one really can
 install a package without help from Cabal. And since packages are the unit
 of distribution, and you want other things like the ability to download
 them from Hackage, this is just fine.

 In contrast, I can work on a multi-module Haskell program without using
 Cabal, and it would pretty horrible user-experience if I had to "install"
 every module before I could use it in another program. So here is what I
 think is the difference of opinion: I want to view Backpack units more as
 modules than as packages (in the old Cabal sense). And the reason for this
 is entirely tied up with small-scale use of Backpack.

 For example: today, if `containers` publishes `Data.Map` which has a map
 data type, I can use it immediately in an hs file, no fussing about with
 Cabal. If someone publishes a `data-map` Backpack unit, which has a hole
 for keys, it would be bad user experience to force a user to use Cabal to
 build and install all the instantiated copies of `data-map` they might
 want to use before they can build their application. To add insult to
 injury, if the key type in question is in the package I was working on,
 they would have separate it out into new unit containing just their type
 definition, so that could be installed first and the used to instantiated
 `data-map`, before they can go ahead and build the package they're
 thinking about.

 So, I think your intuition is right when holes are roughly "package"
 shaped. But I think it's quite important to have reasonable non-Cabal
 workflow when the holes are smaller, which forces us to have GHC
 instantiate things on the fly, which leads us to fat interfaces.

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