[Haskell-cafe] More on dynlinking

[Simon Marlow]

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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe