How are you planning to do modules and plugins? In mdbook we enabled plugins by shelling out to an executable, piping input to it as JSON, then reading back the result, but that’s probably not going to work for something performance critical and frequently called like an AST transformer.
In my FFI guide I have a chapter about dynamic loading and plugins, where you can load a DLL at runtime, invoke a known “register” function, then use the trait object it gives you as a plugin.
May I suggest using Web Assembly as something like a “scripting language” for plugins. That way plugins can be loaded and unloaded dynamically, can be used cross-platform, and run in an isolated environment, so you can safely download and run untrusted plugins, which would be another advantage over the software you’re aiming to replace. The obstacle is just that there doesn’t currently seem to be a high performance Web Assembly host available to embed in Rust. I hope there will be one soon, and that this will be a new standard for loading plugins.
I like the idea of using web assembly for plugins! It’d solve the problem of cross-compilation and would be considerably safer than dynamically loading DLLs. I know parity have a wasm VM which they use for their blockchain client, so that may be a possibility.
You also have an advantage in that WASM is amenable to type-checking and inspecting the signature of a function, which helps reduce the amount of unsafe code necessary.