Yes, that's why it is much more include-like than import-like. Still,
I see this work as something to be done in two phases:
- first, design a true AST for Bison
something to represent the grammar we read. We have more or less
something like this in Bison, but much work is done on it, it's not
"faithful" to the entry, it's already heavily modified.
Once this AST done, then be ready to process it for real, applying
all the transformations we want (elimination of useless things,
elimination of symbolic names, elimination of mid-rule actions, fuse
the %unions, run semantic checks etc.).
Maybe we can think about other transformations, such as inlining
injection rules (see TODO).
- once we have this AST, it should be reasonably straightforward to
implement the fusion of ASTs, hence to have a nice import
implementation.
This AST should also be a tremendous help to debug: it should be able
to print intermediate states for debugging the transformations.