Further to the previous message about modules and imports, 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. That’d obviously make the top level ambient context of a module of Haskell into a sort of monadic action, so it’d be a bit weird, tho at the moment who’s to say what it is anyway? It’s certainly not something that’s first class to the language or able to be programmed as it stands. I suppose this is sounding a little like I’m interested in homoiconicity in some sense, and that’s probably not far from the truth. The main reason I would find this useful is similar to what Sylvain was saying about storing modules of code in databases. I have a system that produces “representations” as Text and then sometimes compiles it as Haskell source (and it’s meta-recursive in that there are many of these little pieces of executed code that then compile others’ outputs, etc)… and even if we don’t have programmatic control over actual compilation or which versions of libraries of code to include, having programmatic control over where the data for modules’ sources comes from would be fantastic. Given that importing is just some magic declaration at the moment that’s kind of outside the language’s programmable constructs, tho, I can’t see that happening without some major reworking, tho, really. Is there appetite for such a thing? One of the things a little strange about the programming industry is how quick we are to invent entirely new languages rather than attempt to modify existing ones and beat them into a new more flexible shape so we can shoehorn our new requirements into a more flexible frame. I realise it’s not always possible, but surely if we all got together and worked on it we could do it? Really, I probably don’t know enough about the internal workings of Haskell & GHC to know if this is crazy or partly reasonable, but crazy ideas are sometimes fantastic, so I’m asking anyway. It would be *glorious* if stack (or cabal, or whatever package manager we use) itself were programmable in the sense that it could be called from within Haskell itself using a typed API and data could drive its included packages, and its type could be a function whose range was IO ByteString, providing the compiled binary. I guess where I’m driving with all this is that it’d be amazing if more of the language and package system and build tools and dependencies were first class and/or have an API just like the GHC API exists because being able to manipulate these things from programs would be great and simplify a lot of currently complex stuff; the only way to do that at the moment is to leave Haskell’s type safety and deal with the textual interfaces in System.Process et al. (I’m actually using System.Process.Streaming, but that’s neither here nor there). I do have a further idea I’ve been pondering for a long while that’s even more crazy than these two, but I might leave that for later, if at all; it has to do with programmability of syntax or lack thereof. Essentially, my system is aiming at keeping everything (source, executables, results of all kinds) separated into small pieces, and results cached so that I don’t have to continually recompile and recompute things that have already been compiled and computed before. It has some of the same ideas as unison in the content hashing sense, tho not the caching at the AST level because Haskell doesn’t work like that, and I’m not interested in building a monolithic unison/smalltalk-style “image/database/world” that has to have everything imported into it — rather the other way around — to have little programs that use parsing, do one thing, and have a typed interface between each of them that glues them all together as and when needed. Apologies that it’s so hand-wavey. Maybe there’s a better place or way to discuss such ideas? If so, let me know. Thanks!