I’m reading the docs, and I get that module is for definitions. I want to make sure I understood:
Can you also have expressions on RHS of assignment? like x=2+3 and y=x-2 ?
No loops or other statements ? Because this Modules · The Julia Language says “… executing all of the statements in a module often involves compiling a large amount of code.”
What else can you have in a module, aside from definitions of variables and functions? macros?
Module is not for top-down execution like a script, right?
Wow, good that I asked! Modules · The Julia Language 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
println(x)
end
end
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.
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.
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 Namespace - Wikipedia , 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.
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”