Why does `Block` reset `Attributes`?

Question

Not even "formal symbols" such as \[FormalX] are guaranteed to always be symbolic. Their Protected argument is forgotten when they are used in Block and consorts, causing functions relying on symbolic variables to misbehave:

foo[n_] := Exponent[\[FormalX]^n, \[FormalX]];

foo[5]
Attributes@\[FormalX]

Table[{Attributes@\[FormalX], foo[5]}, {\[FormalX], 
  1}](*or Block[{\[FormalX]},...]*)

5

{Protected}

{{{}, 0}}

Why does Block clear Attributes? Is Unprotecting and changing a (system) symbol so common that it was decided that Block should do the Unprotecting unsolicitedly?

Is the only way to be sure that some symbol does not have an OwnValue to use Module or Block?

Answer 1

It is illustrative to compare Block, Internal`InheritedBlock, Module, and With. Both Module and With create unique versions of the variables which are not accessible from the outside (lexical scoping, and not without its issues), e.g.

x = 2 y^2 - 7;
With[{y = 5}, x]
Module[{y = 5}, x]

where both With and Module return -7 + 2 y^2. With has the added ability to bypass Hold attributes, which is very useful sometimes. Because of this, it would be difficult to use them to run arbitrary code passed in by a user. In contrast, Block and Internal`InheritedBlock allow you to temporarily augment/overwrite an existing variable, and guarantee that the changes are reset.

A useful example of augmentation, is automatically resetting changes made to default Options, e.g.

Internal`InheritedBlock[{Plot},
  SetOptions[Plot, PlotStyle -> {Red, Blue, Green}];
  Options[Plot, PlotStyle]
]
(* {PlotStyle -> {Red, Blue, Green}} *)

vs

Options[Plot, PlotStyle]
(* {PlotStyle -> Automatic} *)

which can be used to generate many plots where the options are uniform, without resorting to crafting a unique theme. A more interesting example is this graphics parser which uses Internal`InheritedBlock to mimic a stack in tracking the state. If you want a more extensive augmentation, though, you still need to Unprotect the symbol. This is where Block comes in as quite often you do not want to just augment the behavior, but overwrite it entirely.

This is the use case for Plot, Table, etc. where the user supplies a symbol/expression that needs to be evaluated without worrying about whether it has *Values. Internal`LocalizedBlock extends this further by localizing things like Subscript[x, 1] which Block cannot handle.

Of course all these can be merged. Consider this answer from Leonid which traces what packages auto-load another package. It uses Module to set up a closure which uses the Villegas-Gayley pattern to augment Needs. Here Block plays the important role of blocking recursive execution.

Answer 2

Block does something very simple: it just (temporarily) removes all definitions directly associated with a symbol, and nothing else. That includes:

• OwnValues, DownValues, UpValues, SubValues, NValues, FormatValues, DefaultValues, Messages, Attributes

All these are considered to be associated directly with the symbol, in the sense that Attributes[x] are considered to belong to x and not to Attributes.

Don't think of this as "Block does Unprotect, then block does ClearAll". Think of it as all symbol properties being reset to the default value, which is empty, {}, except for some special builtins such as $ContextPath or $Assumtpions.

Related:

• Copying one symbol into another

Answer 3

This is not an answer as to why, wolfram-language-design wise, but to how:

It seems Block[{x = new}, ...code...] effectively does the following:

newValue = new;
allValues = allValuesAndAttributesAssociatedWith[x];
Unprotect[x];
ClearAll[x];
x = newValue;
try {
    ...code...
} finally {
    allValuesAndAttributesAssociatedWith[x, allValues]
}

where the pseudo-code finally-block is executed no matter what happens inside ...code..., even on Abort or Throw.

I tried to capture the exact order of execution of all steps.

ClearAll[x] clears all kinds of attributes and values associated with x, including Messages, FormatValues etc.