(Yes, this is very vauge, because I've just had a vague idea brewing and haven't had time to spend on trying implementation yet.)
If you're not exactly certain what an ECS is, check out specs' overview and the RustConf 2018 closing keynote.
ECS seems to be a very common pattern for modern design work, especially in Rust. It's not hard to see why; it cleanly separates state from behavior, promotes useful composition, (and works around the borrow checker).
ECS has most actively been applied in game development (isn't that where it first got somewhat big and trendy), but I've also seen it used for web server backends and UI frameworks (with varying levels of success).
Parsing itself is, unfortunately, mostly a serial problem, but it's a fast one, and one that you can easily parallelize over multiple input files (so long as you know the set of files to parse ahead of time (a feature Rust doesn't have due to how mod
discovery works)).
I know rustc is (or will be) architected around a core query system. Very simply, you give it the input files and then ask questions like "what is the type of std::option::Option::Some
", "is the trait crate::traits::Foo
object safe", and "what is the rlib
for the library crate"? (Very simplified.)
I'm wondering how/if we could apply an ECS-inspired architecture to a compiler setup. I have a vague idea that each symbol would be an Entity, and various specifics like types could be Components, and it would solve the cyclical nature of compiler logic (symbols can refer to each other, so one needs to be encoded pointing to a tbd at the very least) in a somewhat structured manner.
I really don't have any concrete ideas beyond "ECS backed compiler framework". It just feels like it could work, but I'm just not sure exactly how. My draft of how my toy compiler's references between symbols feels like it'd be a pseudo-ECS store addressed by fully-qualified-name even if I don't use specs.