RFC: ghc's dynamic linker

[Duncan Coutts]

On 27 Aug 2002 15:32:53 +0100
Alastair Reid <alastair@reid-consulting-uk.ltd.uk> wrote:

> > People want to write programs using Haskell as an extension
> > language.  Think of a plugin system or an embeded language. This is
> > currently possible with ghc but requires some cunning hacks and
> > fiddling with the linker and it has some limiations.
> > [...]
> 
> It seems like what you're asking for is partly covered by the
> foreign function interface specification

I'd really like to do it without using the ffi. It would be possible to
use a C interface between the main program and the extension modules but
this would make it much harder to use and restricts the way data and
control is passed between the modules. It also seems unncecessary as all
we're trying to do here is link Haskell code with Haskell code! An
advantage of using the ffi would be that we could use proper .so files
and the system dynamic linker.

ghci does all this quite nicely already, I want the same functionality
avaliable for other programs to use. There is one crucial difference
however, ghci assembles 'other' progams albeit within its own address
space. A plugin system needs to link things to itself.

> It'd be good if you could express your request in terms of things not
> provided by this interface, provided in an awkward or inappropriate
> way, etc. (bearing in mind that the ffi is often accessed indirectly
> through preprocessors like GreenCard, c2hs, hsc2hs, KDirect, HDirect,
> etc. which can eliminate much of the awkwardness).

The thing is I'm not really linking to foriegn code, I'm just linking a
Haskell program on the fly rather than statically. If this were to be
done through the ffi perhaps it would be an extra language-dependant
target - Haskell! Actually this might be a good approach for a
semi-stable ghc ABI to enable .so 's to be useful. That's much more
ambitious than what I need.

If I've not been very clear, let me try to explain by example.

Every decent editor / IDE has an embeded scripting language of some
sort. Emacs has elisp for example. A Haskell IDE should really have
Haskell as its embeded / enxension language so that us Haskell hackers
don't have to learn elisp to make modifications to our programming
environment.

One could embed hugs into your editor / IDE and provide it with some
extra IO () primitives for accessing / modifying the state of the
editor. It seems much nicer to reuse the exsisting framework we have in
the ghc runtime system. In fact this is possible at the moment if we
were to load the IDE in ghci and then use ghci to load up extension
modules. Done like this, the distinction between internal module and
external plugin modules dissapears. So under that model we have an
external agent, ghci, linking the IDE to its extension modules at runtime.
The dependancy on ghci is unsatisfactory however so it would be nice to
be able to move the linking ability from the external agent into the
'host' program itself.

Perhaps the calls from the host program to the extension modules
could/should go via the ffi. (eg each module exports a pluginInit or
main function or something) But calls from the plugin into the the host
program can be direct since it knows all about the program it has been
linked into since it imported the IDE's API module. 

It's just a matter of delayed linking, the plugins could be statically
linked without any problem. Creating a plugin would be no different to
writing an internal module exept for the module dependancies and the
delayed linking.

If this could be done through the ffi in a reasonable way, I'd be
interested to hear about alternatives particularly if the ghc
implementors say this ghci style dynamic linking stuff is too difficult
or silly!

Duncan Coutts