Local variables in Module leak into the Global context

Question

From the Mathematica documentation on Module:

Module allows you to set up local variables with names that are local to the module.

But after using Module, the symbol is created !

I understand that Module makes temporary symbols appending a number, like i$8071 and those are gone afterwards. However the symbol i is newly created, but has no value or attributes.

Here is a very simple session showing this.

Names["Global`*"]
{}

Module[{i}, Table[i^2, {i, 0, 10}]]
{0, 1, 4, 9, 16, 25, 36, 49, 64, 81, 100}

Names["Global`*"]
{"i"}

Attributes[i]
{}

This is not causing me any specific trouble currently, but I want to ensure that the code I'm developing is "clean" in that it doesn't pollute the Global namespace with new symbols. Could these unwanted symbols cause trouble by shadowing symbols from other packages for example? Should I just not worry about it? How can I check that my code is "clean"?

Answer 1

Symbols are created in the current context during parsing. This should not be a problem in normal circumstances as the symbols are merely "initialized" without values or properties.

See these posts for more information:

• Is it possible to use Begin and End inside a Manipulate?

• Why doesn't this use of Begin[] work?

• When does Mathematica create a new Symbol?

• Scope within Context

---

You raise good questions in the comments and I need to address them.

Shadowing

Indeed you can have problems with shadowing due to this. I intended the linked questions above to serve as examples of (and possible solutions to) this problem, but here is a short description. In a new session, if you do:

Table[x, {x, 3}];

session`x = 5;

AppendTo[$ContextPath, "session`"];

Information["x"]

Global`x

You can see that even though x was used in a localizing construct (Table) the Symbol Global`x was created. This then causes a shadowing problem if we also define session`x and hope to access it with merely x by including "session`" in the $ContextPath.

There are some alternatives to the bare form above that prevent the creation of Global`x.

Precedence of initialization

If you know you are going to use session`x you can initialize it first, and then if the context name is in $ContextPath the appearance of x in Table will be assumed to be session`x (Global`x will not be created):

session`x;
AppendTo[$ContextPath, "session`"];
Table[x, {x, 3}];
Information["x"]

session`x

Formal Symbols

You could use Formal Symbols in constructs like Table, Block, and With and Module. These symbols exist specifically to prevent conflicts of various kinds as they bear the attribute Protected and cannot accidentally have values assigned to them. (These are entered with e.g. Esc$xEsc and look much better in the Notebook than they do here.)

Table[\[FormalX], {\[FormalX], 3}];
session`x = 5;
AppendTo[$ContextPath, "session`"];
Information["x"]

session`x

x=5

Begin and End

You can use Begin and End, but as the second linked question above shows you have to be particular in their use: you must evaluate Begin on a line before the code that uses the symbols you do not want to "leak" to Global`:

Begin["session`"];

Table[x, {x, 3}];

End[];

Information["x"]

Information::notfound: Symbol x not found. >>

It cannot be rolled into a Module or other compound expression because the expression is parsed as a whole before Begin has any effect. (Workarounds do exist; see the answers to the first linked Q&A above.)

Module[{null},
  Begin["session`"];
  Table[x, {x, 3}];
  End[];
]

Information["x"]

Global`x

The mechanism of Module

You asked of this statement was correct:

Module only makes the value (and Attributes) of the symbol "local". The symbol still gets created in the current Context (Global by default), and can therefore shadow any similar name from another Context.

It is not. The creation of the Global` symbol (or as you correctly note whatever the current context is) is merely incidental to its use in Module. Module has nothing to do with it one way or the other, as it occurs during parsing, before Module even has any meaning (it is just another token at that stage).

For reference, Module works by creating a new symbol with a name based on the one you give it (x), appending $ and an incrementing number to form e.g. x$173. This symbol is then used in place of all explicit appearances of x inside the Module. This new symbol is not itself replaced with x at the end so you will see the internal form if it is returned in the output of Module, e.g. Module[{x}, x]. See this thread for a more complete description and a comparison to other scoping constructs:

What are the use cases for different scoping constructs?