In reply to @pmunch "Well Nim 3 focuses": If my understanding is correct,
"plugins" are tiny binary executables to transform one NIF to another NIF, and
compilier will pick up the transformed NIFs (transformation in parallel!) and
insert back to original AST to form a no-macro NIF. This happens after semantic
analysis, basici transformations (like iterators).  To make the legacy macro
system (NimNode based) work, essentially, each macro will be wrapped and
compiled to a plugin, the wrapped plugin binary will take in one NIF file,
translate the NIF AST to NimNode AST, run the original macro to transform the
NimNode AST, then the wrapper will dump NimNode back to NIF, and save to disk.
So legacy macro will have two more steps to bridge NIF and NimNode. This should
be fine, as NIF processing could be cached and paralled, so presumably much
faster than VM. Just, if there are many tiny NIF files (NIF on macro level?
module level?) on disk, filesystem could be quite slow. Maybe someone will
design a sqlite like database to manage NIF files for faster IO.