#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