Just a comment: it's, well, interesting how GHC has this fantastic method of importing modules at runtime, which is similar (at least in what it achieves) to the dynamic linker. I dunno, it feels like reinvent-wheel syndrome. Not saying that's a bad or good thing, just an observation.
I've played with dynamic linking quite a bit myself. The problem with dl_open and friends is that it was designed with very, very narrow goals and the API doesn't provide anything not required to meet those goals. It would be quite straightforward for the library to support multiple namespaces so that you can load two versions of the same library and have some of your code use one namespace and some use the other namespace. No joy. (I don't think GHC needs this but it's something we wanted for Knit. Knit is a component-programming extension of C - if you think 'ML functors', you're in the right ballpark.) It would probably be trivial for the library to provide a way to say 'Please insert symbol "X" into your lookup table' but it doesn't. (IIRC, this is the essential function that the standard library lacks.) -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/