Robert Dockins wrote:
[...] In particular, if we could segment closely related code with many interdependencies into discrete units with well defined external interfaces (sound like packages to anyone else?), then my intuition tells me that the cost of setting up an inlining barrier should be fairly low. Module inlining _within_ a package would still occur, just not _between_ packages.
This reasoning might be valid for traditional languages, but not for languages like Haskell promoting the use of higher order, typically small functions. Not inlining most monads would probably be catastrophic, as would be not doing so for our beloved map, foldr, etc. And IMHO C++ has given up this kind of binary compatibility completely lon ago when code in headers was introduced, so Haskell is in good company with one of "the" languages in use. Not really a good excuse, but a fact... And just a remark: We don't need a new technique for a "no inline barrier": Just compile the library optimized and use a facade which re-exports your public API compiled without optimizations. Cheers, S.