RFC: ghc's dynamic linker

[Duncan Coutts]

On Wed, 28 Aug 2002 12:20:31 +0100
"Simon Peyton-Jones" <simonpj@microsoft.com> wrote:

> 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.

> 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.)

You mean that the API module won't accidentaly get identified as dead
code and removed at link time. (which is nice :-) )

> This approach is v simple, it would satisfy Duncan's need (I believe),

Simple is good!

> it could be made more secure using dynamic types (addEntity and 
> lookupEntity are good moments to typecheck), and it doesn't suffer from
> the disadvantages that Simon M mentioned. 

We still have the problem that some modules need to be loaded in
their entirity or suffer from loading things multiple times and the
wierdness that goes with that?

To allow sharing of whole packages really would require access to the
symbol table, I suppose, since a package contains loads of symbols. For
what I want to do however this is probably ok since plugins probably
shouldn't be using stdin/stdout anyway. Are there any more serious
issues with loading two copies of the standard libs?

Also, is there any way of identifying the dependancies of a ghc-generated .o
file, or does ghci use the .hi files?

If people think this is the right approach(tm) and it's possible to
implement without being a ghc uberhacker then I'll have a go - any
assistance welcome of course. (What have I let myself in for!)

Duncan