[Haskell-cafe] More on dynlinking

[Robert Dockins]

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