RFC: ghc's dynamic linker

[Simon Peyton-Jones]

| Going the final step and allowing linkage to the current=20
| binary is possible, it just means the linker has to know how=20
| to read the symbol table out of the binary, and you have to=20
| avoid running 'strip'.  I believe reading the symbol table is=20
| quite straightforward, the main problem being that on Unix=20
| you don't actually know where the binary lives, so you have=20
| to wire it in or search the PATH. =20
|=20
| Another problem is that you don't normally link a *complete*=20
| copy of the base package into your binary, you only link the=20
| bits you need.  Linking the whole lot would mean every binary=20
| would be about 10M; but doing this on the basis of a flag=20
| which you turn on when you want to do dynamic linking maybe=20
| isn't so bad.

There is another option too, which I find quite attractive. To the
interface that Simon mentioned:

|    loadLibrary  :: FilePath -> IO ()
|    lookupEntity :: String -> IO a

add one more call:

     addEntity :: String -> a -> IO ()

The effect is to extend GHCi's dynamic linker's symbol table with
an extra binding.   So that 'lookupEntity' of the same string would
return the value you stuffed in with addEntity.

Why is this useful?  Because it enables the 'main Haskell program'
to populate the symbol table with the symbols that the plugins need.
I'm guessing that the dynamically loaded plugins will not need very many
entry points to the main program, so the 'populate symbol table' code
would look like
	do { 	addEntity "foo" foo ;
		addEntity "baz" baz; =09
		..etc..


One nice feature is that this automatically makes sure that the
main program mentions 'foo', 'baz' etc, even if only the plugin
is meant to call them.   So that makes sure that when linking the main
program, all the relevant bits are linked in.   (Simon mentioned this
problem in his message.)

This approach is v simple, it would satisfy Duncan's need (I believe),
it could be made more secure using dynamic types (addEntity and=20
lookupEntity are good moments to typecheck), and it doesn't suffer from
the disadvantages that Simon M mentioned.=20

Simon

PS: I'm working on an upgrade to GHC which, among other things,
happens to eliminate the need for initLinker