Your suggestion amounts to giving the programmer more control over the ABI compared to the current extreme options: (a) -O0, ABI == API (b) -O[12], ABI == entire implementation + ABI of dependencies in addition, the ABI includes the version of GHC that compiled the code. Providing an option somewhere between (a) and (b) seems reaonsable. Making the details work out is pretty tricky: for example, you can't inline the definition of an unexposed function into an exposed function. Indeed, the inlining of an exposed function can't depend even on the type of a hidden function. Cheers, Simon On 07 December 2004 14:24, Robert Dockins wrote:
What if (go with me here) we invent a new aggregate unit of haskell code, and we call it a library, and we design libraries with the express intent of allowing dynamic linking. We would desire:
1) True dynamic linking for reduced memory (and disk) footprint and drop-in replacement
2) ABI versioning (because its a mess otherwise)
3) Acceptable performance penalties, by still allowing inlining of some code
I propose something along these lines. Libraries are composed of some number of modules. A module is either an "interior" or "boundry" module; the library author somehow distinguishes the boundry modules. The library is compiled as normal and the object files are packeged together. The .hi files of _boundry_ modules are combined into a single library-wide interface file, which is then packaged together with the library code. The interface file would contain a) the definition of any functions _declared_ in a boundry modules b) datatypes and classes _exported_ from boundry modules c) the types (but not definitions) of any functions re-exported through a boundry module d) instances for classes which are either imported from elsewhere or exported from a boundry module e) a version number (eg, with major, minor and build numbers). The library-wide interface file, and the sybmol names of closures for the exported functions then constitute the ABI.
Future changes to or deletions of elements in the interface represent an incompatable change, whereas additions would be compatable. Libraries can then have their version numbers incremented when incompatable changes are made.
This method then allows the library author to decide where to trade off possible optimizations for implementation hiding (by deciding what to put in boundry modules). Things ripe for inlining and unlikley to change, like monad definitions, could go in the boundry modules, whereas more volitle heavyweight code could stay in the interior. To get behavior similar to the current package behavior, just declare all modules boundry modules, but still reap some of the reduced footprint advantages.
OK, those are my thoughts, flame away, :)
Robert Dockins
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe