# Is there a way to make a submodule "open"

**URL:** <https://discourse.julialang.org/t/is-there-a-way-to-make-a-submodule-open/49641>\
**Category:** General Usage\
**Tags:** module, scope\
**Created:** [November 5, 2020, 8:58pm UTC](https://discourse.julialang.org/t/is-there-a-way-to-make-a-submodule-open/49641 "2020-11-05T20:58:46Z")\
**Posts on this page:** 2\
**Page:** 2

<div class="post-metadata">

**Author:** ![mhinsch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mhinsch/32/26676_2.png) [@mhinsch](https://discourse.julialang.org/u/mhinsch)\
**Post date:** [November 11, 2020, 11:56am UTC](https://discourse.julialang.org/t/is-there-a-way-to-make-a-submodule-open/49641/21 "2020-11-11T11:56:06Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![c42f](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/c42f/32/52842_2.png) [@c42f](https://discourse.julialang.org/u/c42f)\
**Post date:** [November 12, 2020, 12:33am UTC](https://discourse.julialang.org/t/is-there-a-way-to-make-a-submodule-open/49641/22 "2020-11-12T00:33:59Z")

</div>

> [@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.

[Previous page](https://discourse.julialang.org/t/is-there-a-way-to-make-a-submodule-open/49641.md?page=1)