Yeah, thanks for the suggestions; I explored the GHC API and hint a few years ago (four). Even contributed to GHC’s linker to allow hint to do multi-layered interpretation when I was using it to build a distributed haskell / cloud haskell backed service that was the precursor to the system I’m building now. Of course sadly Cloud Haskell has been pretty much dropped in the last few years, so that possibility went away, and Hint is primarily aimed at interpretation not compilation, but I realise you’re suggesting to use hint as an example of how the GHCI API could be used, not saying to use hint itself necessarily. However I’m interested in compilation not interpretation.

If I understand what you’re suggesting, I think it’d become pretty tedious if every single module we wrote had to import the GHC API just so it could import other modules? I wasn’t intending that imports should be dynamic, just that it’d be nice if it were more explicit about exactly what an import meant, in the sense that other Haskell expressions are, and thus more first class, which would allow using Text as source, and obtaining that source from a database or some other place just as easily as off disk.


68.png
Multiple embedded interpreter instances · Issue #68 · haskell-hint/hint
github.com



On 5 Dec 2024, at 7:59 AM, Isaac Elliott <isaace71295@gmail.com> wrote:

> what would be *really* useful would be if importing was in some sense “just a function” in IO or some other Monad and therefore also if modules were represented as some Haskell data structure.

You can do something like this using the GHC API. A program that depends on the `ghc` library can parse and compile a module, and then look up module bindings by name and (unsafely) coerce them into normal values. See `hint` (https://hackage.haskell.org/package/hint) for some inspiration.

I was playing around with this sort of thing because I wanted to use Haskell modules as plugins for a program that I wrote. I got it working - the program could load and run the plugin module - but decided to go back to a fraught stringly-typed interface between two separately compiled processes.

One reason was that the dynamic loading approach was too slow, and I wasn't interested in figuring out how to make it faster.

Another reason was that my program is intended for use in certain Haskell projects, and it's unlikely that the GHC compiler embedded in the program will match the version that the user has for their project. I didn't want to allow the user to write code that compiles with their GHC but not when loaded into my program (e.g. if their GHC version is newer and they use a new feature).