Module basics



I’m reading the docs, and I get that module is for definitions. I want to make sure I understood:

  1. Can you also have expressions on RHS of assignment? like x=2+3 and y=x-2 ?
  2. No loops or other statements ? Because this says “… executing all of the statements in a module often involves compiling a large amount of code.”
  3. What else can you have in a module, aside from definitions of variables and functions? macros?
  4. Module is not for top-down execution like a script, right?

Thanks in advance!

  1. Yes. You can have anything in a module, it is just a namespace.
  2. Same as 1. The section you linked is about precompilation which is a way to cache some of the things that need to be done when loading a module.
  3. Anything. All packages have all their code in one top level module.
  4. Yes it is.


Wow, good that I asked! gave me the wrong intuition, it NOWHERE clarifies all that.

So I can have an full program in a module!
say like this:

module mine
x="hello world!"
for i in 1:3 


And how would I execute it, just like a script , with julia mymodule.jl or, in Repl, include("mymodule")??

By the way, when you say “just a namespace” you assume everyone knows what a “namespace” is, which is far from true… Besides, julia docs don’t define it, and I can’t rely on google, as it may be different from other progr. langs.


yep, that works

Related, particularly w.r.t “Main” module: Scope of a script file


That may not be the best way to go about this. I would recommend programming the components of a complex program in modules, so that they can be unit tested etc. Then have a small script start the program.

For a trivial script, you don’t need a module at all.

Also, the docs you linked talk about __init__.


Well, I meant I can have a “program” at all (i.e, something that is run top-down, not just something consulted for definitions).

I would recommend programming the components of a complex program in modules

How about 1 module, but with the components in many functions inside it?


This is of course up to you, depending on code complexity.

Of course you can, I just don’t think it is a good way to organize that part inside a module.




With respect to “namespace” meaning (as it was mentioned in the Ist and IInd replies):
it turns out modules in Julia are not “just namespaces”, which, according to , would be an organized set of symbols and their definitions.
Modules in Julia can be used for pretty much “everything” according to answers above.
That means Julia documentation maintainers should do their best to avoid their personal previous background bias when explaining things – the audience may misunderstand them.


Wikipedia is not the one source of truth. That definition doesn’t exclude having unnamed things or just actual code inside of a namespace, it only requires having the ability to group named things and allow duplicate names by nesting them.


It’s not possible to change (value of ) global variables remotely, from within other modules, is it?
Because says:

Note that variable bindings can only be changed within their global scope and not from an outside module.

But the “(!) Avoiding globals” box note in suggests otherwise with

[…] remotely changing the state of global variables in other modules should be done with care […]


You can not change the binding from an outside module:

julia> module Foo
       x = 3

julia> Foo.x = 2
ERROR: cannot assign variables in other modules

But you can change the state (content) of a (mutable) variable

julia> module Bar
       x = [1]

julia> Bar.x[1] = 2

julia> Bar.x
1-element Array{Int64,1}:


OK, good to know that.
But that note is still misleading, as I think its intent was actually to explain the rationale for using global to change the binding of a global variable, from within a local scope, so I guess it should be replaced with:

Avoiding changing the binding of global variables is considered by many to be a programming best-practice. One reason for this is that changing the value of global variables should be done with care as it makes the local behavior of the program hard to reason about. This is why the scope blocks that introduce local scope require the global keyword to declare the intent to modify a global variable.

– assuming, in this form, it’s still a “programming best practice”


I also think that warning box reads quite oddly so an improvement would definitely be nice.