[Haskell-cafe] Re: Non-technical Haskell question

[Sven Panne]

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.