I don't understand something about this discussion which is probably just ignorance on my part, so apologies in advance. Or, perhaps what I'm thinking doesn't apply in all environments. Watching what happens when ghc compiles a module (this doesn't apply to ghci, just to compilation), the executable is actually created by a call to gcc. Gcc is already capable of linking statically, creating a program that can run without the presence of ghc on a machine. Furthermore, when a (normally, that is, dynamically) linked executable (created by ghc) is executed, the dynamic loader is not anything specific to ghc but is just the normal O/S dynamic loader (typically ld.so). So, if the code can be executed by the O/S with ld.so, the symbol table is already present. I ran a quick test on these ideas and was able to run executables produced by GHC on systems that have no part of GHC installed. What am I missing here? TIA, On Tuesday 27 August 2002 07:32, Alastair Reid wrote:

Duncan Coutts writes:

...

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

http://www.cse.unsw.edu.au/~chak/haskell/ffi/

especially foreign export (section 3.4), dynamic wrappers (section 4.1.3), and hs_init and friends (section 6.1).

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

-- ----------------------------------- Seth Kurtzberg M. I. S. Corp. 1-480-661-1849

On 27 Aug 2002 15:32:53 +0100 Alastair Reid 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