[I’m not a fan of the current *implementation methodology* of the PPX subsystem, but] I doubt it’s possible to give a full-power macro-system for a language, without inevitably being forced to make some hard choices. The PPX/OMP/ppxlib designers have chosen among them, and while I might disagree with their choices, they -are- on the menu of choices that lead to a powerful macro sysetm. Here are some of the choices:
(1) [I don’t know Rust’s macro system well, but last I looked, it wasn’t very powerful] You allow only a restricted macro system, so you don’t have to implement deep support for pattern-matching/construction of ASTs
(2) You allow very powerful macros (basically able to take apart and rebuild arbitrary code fragments) and then you’ve got some more choices to make:
(a) via something OMP, you allow for version-to-version compatibility as the AST type itself changes [con: yeah, gotta maintain OMP]
(b) you commit to fixing all existing PPX rewriters soon after each major Ocaml release [con: ouch, lotta work, also wow, talk about chaos]
(c ) you eschew binary AST communication between the macro-system and the compiler; and since concrete syntax changes very, very slowly, this allows you to change the AST type in the compiler without blowing up the macro system [con: slower, maybe also more fragile]
ETA: by this I mean, use source-code as the comms format between PPX and compiler. This is obvs slower, somewhat fragile, and also prevents any decent attempt at mapping errors back to source-code locations.
(d) you use a very “loose” AST type in the macro-system, so that minor changes of the compiler’s AST type don’t induce changes in this loose AST type [con: errors at runtime that might have been caught earlier]
Of course, #2a is the current course-and-speed. #2d has been proposed, and while it seems attractive, I think it’ll be more trouble than it’s worth.
I don’t see how shifting the work onto the compiler team helps: they still need to maintain compatibility with code written against older versions of the compiler, which might be expecting a slightly different AST type, which leads to these same choices.
Now, I -do- think that it’s possible to make OMP much cheaper to build, maintain, and use, using PPX rewriters. I’m in the process of prototyping that right now. But that’s neither here nor there: the truth is, something like OMP is … necessary.
Or at least, so it seems to me.