Is there a way to make a submodule "open"

[mhinsch]

One final remark concerning the subverting of most module functionality (as @c42f said). I guess that depends a bit on which direction of encapsulation (outside → inside or inside → outside) you consider more relevant. I actually prefer Julia’s choice of insulating modules in both directions over something like C++ which has namespaces open to the outside, but I think there are situations where it would be handy - especially with local submodules - to be able to have automatic access to the surrounding namespace.

[c42f]

@mhinsch

All of that said (rather long-windedly), I guess in the end it’s largely a matter of taste which solution you prefer.

In this case I think it’ll come down to the detail of how you plan to use it (managing the state and utility functions as you said) so the choice can’t be made without those details. It’s nice to see the concrete use case

@mhinsch

Many macros are essentially just (very) glorified syntactic sugar, i.e. in principle you could write their results by hand. Part b) becomes much easier if the macro produces code that is similar to what you would end up with if you didn’t have the macros.

Yes macros are exactly user-defined syntactic sugar. In the compiler, the first part of code lowering after macro expansion is to deal with all the built in syntactic sugar. The code which does this functions exactly like a macro expander (just working on built-in Expr heads rather than Expr(:macrocall)).

When designing complex macro-based interfaces I find it’s extremely useful to write out the code you want the macro to generate by hand to check that the implementation works. When it works for a couple of test cases, then try to write the actual macro. One way this helps is to separate the code which must be generated from any utility functions which the generated code can call.