I’m not an expert by any means. But I do have some experience with procedural macros and how they’ve been done in the Scheme/Racket community/literature.
Why I’m scared Procedural macros + modules seems to have broken the Scheme community – most notably, Racket seems to have splintered off due to the schism over simplicity vs. power in the Scheme language. I don’t have a source, but it seems to me that Scheme has reverted to its R5RS roots in its most recent standard of R7RS-small, and procedural macros were carved out of the language.
Is breaking hygiene within scope for procedural macros? It appears that Rust is already equipped on nightly with reengineering attempt to adjust the parser to produce syntax object-like things with “sets of scopes” to unique define what scope a binding falls in (similar to Flatt’s 2016 “Bindings as Sets of Scopes” for Racket’s new macro expansion scope-tracking system). Furthermore, how much affordance are given to macros that are used incorrectly if they break hygiene? How nice will the error messages look?
- Non-procedural macro crates can invoke procedural macro crates. Since procedural macro crates can be arbitrary Rust code, they are also free to produce any side-effects and introduce bugs into the compiler runtime, as a whole. Imagine: when a procedural macro crate fails to terminate or creates a fatal error, what will stop users from thinking, “Oh, wow, Rust is failing,” when it’s actually a procedural macro crate that’s causing the problem? From what I understand,
Isolation of procedural macros
Could it be possible to isolate the execution of procedural macros? And is there a way to limit the types of side-effects that are able to be performed by the compiler proper? I’d like to think a permissions system could be done where the crate can be given access to a camera or a database through a permissions-based system so that only certain compile-time crates would be able to access “juicy features” so that if anything goes wrong, you’d be able to pinpoint the problematic crate in question.