| > I would like to see GHC support fixed ABIs, and the work I did with | > ABI hashing in GHC was aiming towards exactly that. | > | > For fixed ABIs you would need to have the user explicitly declare | > every inline function, and then hash the definitions as part of the | > ABI. (also do something about strictness and arity, and other | > cross-module optimisation hints). It might be painful, but it could | > be optional, and the gains are quite nice: the ability to upgrade a | > library in-place without recompiling everything that depends on it. | > Especially now that we're moving towards shared libraries, this would | become more useful. | | Yes that would be really wonderful!! | | The current ABI situation is really very painful for packagers and | beyond IMHO. To me it is actually the largest current problem with ghc. Indeed. Offering fixed ABIs is something that Simon and I have often discussed, but never acted on. Why not? * There is significant design work to be done. Exactly how does the programmer specify which inlinings, strictness, arity etc appear in the ABI? What if the implementation of a function changes so that its strictness or arity really is different? * There is significant implementation work to do. Apart from anything else, we presumably do not want to inhibit cross-module inlining etc *within* a package. Currently GHC uses the same M.hi files *within* a package as *between* packages. So maybe we need to strip down these .hi files somehow for use cross-package; or generate a one-per-package portmanteau .hi file? That's real work. * There will be a performance penalty for reducing cross-package inlining. We don't know how much, and it's hard find out without doing the work of the earlier two bullets. So, if we want fixed ABIs then lots of people are going to have to help, including help lead! Simon