There are a number of problems: 1. There is no support for mixed Backpack/regular module projects, and it's not altogether clear how you would implement it, since it's not obvious from file naming where a "module" might live. This is in contrast to something like anansi which generates hs files so that the existing lookup codepaths work. 2. Recompilation avoidance operates on an entire bkp file, so if you modify any submodule, you have to rebuild everything. Not great if you actually have a lot of code. 3. GHCi doesn't know how to deal with bkp files at all. bkp files also support defining multiple libraries, which is a phase violation with Cabal, and not really solvable at all. Edward Excerpts from Yuras Shumovich's message of 2017-03-28 16:43:54 +0300:
28-03-2017, Аўт а 09:22 -0400, Edward Z. Yang напісаў:
Excerpts from Yuras Shumovich's message of 2017-03-28 12:23:36 +0300:
Also, I think backpack has some limited support for multiple modules in one file. At least I saw something similar in backpack examples in Edward Yang's blog.
You can put multiple modules in a bkp file, but that is mostly a tool for compiler tests, and not intended to be used for "real" software.
Thank you for clarification. Yeah, I think I saw it on GHC Trac too. It is very neat! But what prevents it from being useful for real software? I often use anansi ( http://hackage.haskell.org/package/anansi ) when prototyping new projects, so that I can write multiple modules in one file. (One .anansi file generates a number of .hs files.) But it is an ugly workaround at best.
Yuras.
Edward