load modules from other sources than disk

[JulianLeviston]

Wasn't sure if #6 relates, and didn't want to co-opt it if it did.

I'm interesed in a function something like loadModules, but abstract away from disk. That is, I'd like to run it in a context where the file sources can be provided as data rather than filenames that then get read off disk as data.

The description of loadModules is:

Tries to load all the requested modules from their source file

...however, I'd like to be able to get inbetween and provide my own source of data that isn't necessarily disk at all. (Like, my source is going to be stored somewhere other than locally, and I am not necessarily executing in a context where I can write to the file system to profide hint with a file).

When I've been running locally in the past, I've just written to disk when I needed to build such contexts, but as I move this piece of software I'm writing outside of a context where the local disk is accessible, this starts to become a bit of a problem, potentially.

---

Looking at the source, it looks like this relies on whatever GHC provides (in this case the load function)... 🤔

[JulianLeviston]

Ah, I'm going to close this, because I just realised I can access a disk, so it'll be fine. I've often wondered if GHC could be made to use non-file system compilation in the past, but for now, I'm all good. Sorry for the additional issue.

[Wizek]

I'm also interested in this. Can we re-open, @JulianLeviston?

Also, new link since the other one got broken: #6

[gelisam]

I don't see how hint could possibly work on a system which doesn't have write access to a disk, as a part of its implementation involves writing a "phantom" module in a temporary folder:

hint/src/Hint/Context.hs

Line 129 in b640d6d

liftIO $ writeFile (pmFile pm) (mod_text $ pmName pm)

That being said, hint's reason to exist is to wrap the ghc API to provide a better API, so hint would be a good package to host a function which takes a module as a string and loads it by writing it to a temporary file.

[JulianLeviston]

@Wizek It'd be nice if GHC allowed compilation to strings, however given that it compiles down to C minus minus I don't know if it'd be possible at the moment.

Haskell generally suggests writing software as a set of libraries rather than apps, and GHC is no exception — it's structured as such. However, it'd be nice if much much more of it were libraries and not so tied to the filesystem, because GHC generally assumes one module per file, which is intimately tied to the filesystem.