# What are some advanced uses for Block?

I read the answers to this question (What are the use cases for different scoping constructs?) and this one (Condition, Block, Module - which way is the most memory and computationally efficient?).

According to those, Block is safer (if something aborts, it restores the values) and faster (perhaps something to do with the low-level pointer redirection that I believe it uses) than Module, but less memory-efficient if the function is defined a certain way.

That being said, (1) why does Leonid say that Module is "safer" when it doesn't have as-good garbage collection, and (2) if I am to use Module for most of the time, what are some of the "advanced" uses which require Block?

## Safety

Module is safer than Block because:

• It is a lexical scoping construct, which means that variable bindings are only tied to a specific piece of code. Variables outside that piece of code are never affected by these bindings.

In contrast, Block basically binds a variable to a piece of execution stack, not a piece of code. Such bindings are much harder to understand and debug, since execution stack is not something carved in stone, it is dynamic and usually data-dependent.

• The way Module resolves variable collisions is such that the integrity of inner or outer level bindings is never broken (at least in theory - in practice the lexical scoping is emulated in Mathematica and can be broken, but let's say this is very unlikely to happen by itself).

In contrast, nested Block-s will simply have the variable value be the one (re)defined most recently, and also those different Block-s can be in different functions - while nested Module-s normally are in one function.

Both these points lead to the same conclusion that code which uses Block is harder to understand and debug. Basically, it is almost the same as using global variables (which are however guaranteed to get back their values after Block executes).

## Advanced uses of Block

Probably the main one is to change the order of evaluation non-trivially, in a way not easily possible with other constructs. Block-ed functions or symbols forget what they were, and therefore evaluate to themselves. This often allows to alter the order of evaluation of expressions in non-trivial ways.

I will show a couple of examples.

### Example: emulating OptionValue

Here is one, from this answer: a possible emulation of OptionValue, which is one of the most magical parts of the pattern-matcher:

Module[{tried},
Unprotect[SetDelayed];
SetDelayed[f_[args___, optpt : OptionsPattern[]], rhs_] /;
!FreeQ[Unevaluated[rhs], autoOptions[]] :=
Block[{tried = True},
f[args, optpt] :=
Block[{autoOptions}, autoOptions[] = Options[f]; rhs]] /; ! TrueQ[tried];
Protect[SetDelayed];]


the usage:

Options[foo] = {bar -> 1};
foo[OptionsPattern[]] := autoOptions[]
foo[]

(* {bar -> 1}  *)


### Villegas-Gayley trick of function's redefinition

(call:f[args___])/;!TrueQ[inF]:=
Block[{inF=True},
call
]


allows you to inject your own code into another function and avoid infinite recursion. Very useful, both for user-defined and built-in functions

### Safe memoization

fib[n_]:=
Block[{fib},
fib[0]=fib[1]=1;
fib[k_]:= fib[k] = fib[k-1] + fib[k-2];
fib[n]
]


The point here being that the memoized values will be cleared automatically at the end.

### Making sure the program does not end up in an illegal state in case of Aborts or exceptions

a = 1; b = 2;
Block[{a = 3, b = 4},
Abort[]
]


The point here is that the values of a and b are guaranteed to be not altered globally by code inside Block, whatever it is.

### Change the order of evaluation, or change some function's properties

Comparison operators are not listable by default, but we can make them:

Block[{Greater},
SetAttributes[Greater, Listable];
Greater[{1, 2, 3, 4, 5}, {5, 4, 3, 2, 1}]
]

(*  {False, False, False, True, True}  *)


### Preventing premature evaluation

This is a generalization of the standard memoization idiom f[x_]:=f[x] = ..., which will work on arguments being arbitrary Mathematica expressions. The main problem here is to treat arguments containing patterns correctly, and avoid premature arguments evaluation. Block trick is used to avoid infinite recursion while implementing memoization.

ClearAll[calledBefore];
SetAttributes[calledBefore, HoldAll];
Module[{myHold},
Attributes[myHold] = {HoldAll};
calledBefore[args___] :=
(
Apply[Set,
Append[
Block[{calledBefore},
Hold[Evaluate[calledBefore[Verbatim /@ myHold[args]]]
] /. myHold[x___] :> x
], True]];
False
)
]


Block is used here to prevent the premature evaluation of calledBefore. The difference between this version and naive one will show upon expressions involving patterns, such as this:

calledBefore[oneTimeRule[(head:RuleDelayed|Rule)[lhs_,rhs_]]]

(*
False
True
*)


where the naive f[x_]:=f[x]=... idiom will give False both times.

Block[{$ContextPath}, Needs[your-package]]  This will disable any global modifications that the package being loaded could make to a given symbol: Block[{symbolInQuestion}, Needs[the-package]]  There are many more applications, Block is a very versatile device. For some more intricate ones, see e.g. this answer - which provides means for new defintions to be tried before the older ones - a feature which would be very hard to get by other means. I will add some more examples as they come to mind. • What exactly does Block do in the noUsage function? – Rojo Oct 5 '12 at 3:15 • WOw, again an amazing answer +1 – Markus Roellig Oct 5 '12 at 8:00 • Great answer... thanks for sharing! – sebhofer Oct 5 '12 at 9:34 • Regarding the safe memory usage when defining functions, which was fib in your example, what's the danger of having all those extra DownValues for fib? In fact, if I kept them, the next time I called fib it would be faster, right? In other words, what is the use of constraining the self-made DownValues (f[x_]:=f[x_]=...) with Block? Does it somehow cause a memory leak? – VF1 Oct 5 '12 at 14:18 • @VF1 This depends on the situation. Sometimes you want to keep them for future calls. Sometimes, however, they are only needed to speed up that single computation, and future calls are unlikely to hit the same arguments. In those cases, keeping these extra defs would just slow down the hash lookup and hog the memory, so they better be removed after the call. Block allows you to do that automatically. B.t.w., a long overdue here on SE question IMO (your main one I mean). Thanks for the accept. – Leonid Shifrin Oct 5 '12 at 14:22 Briefly, Block allows you to temporarily change global definitions and functions in a way that Module does not. This is both its strength and weakness. If you use Block[{x = 5}, (* stuff *)] without realizing that something deep inside "stuff" relies on x you may break things. On the other hand you can use this power intentionally to do some interesting things. ### Change global settings With a recursive definition for Fibonacci numbers: f[0] = 0; f[1] = 1; f[n_] := f[n] = f[n - 1] + f[n - 2]  We need a larger value for $RecursionLimit to get the 300th number in the series:

Block[{\$RecursionLimit = 500}, f @ 300]


222232244629420445529739893461909967206666939096499764990979600

### Change the meaning of built-in syntax

listSample := {12*12.5*13*13.5*14*14.5, 12*12.5*13*13.5*14*14.5};

Block[{Times = List}, listSample]

{{12, 12.5, 13, 13.5, 14, 14.5},
{12, 12.5, 13, 13.5, 14, 14.5}}


### Change the behavior of some internal functions

One can use this method to Save only the direct definitions of expr, rather than also all linked definitions as is the default behavior:

Block[{FullDefinition = Definition},
Save["filename.m", expr]
]


### Temporarily clear definitions

x = 1; (* global definition *)

D[Sin[x], x] (* this now fails *)


General::ivar: 1 is not a valid variable. >>

Solution:

Block[{x}, g[x_] = D[Sin[x], x]]


We now have the correct Definition for g: g[x_] = Cos[x]

• Are those really the only uses? Everything you mentioned goes under "temporarily clear definitions" to me. – VF1 Oct 4 '12 at 22:32
• @VF1 What applications are you envisioning? Those are pretty useful abilities IMHO. – Mr.Wizard Oct 4 '12 at 22:37
• I do not deny that your abilities are indeed useful. But those were things that I already knew and ones that Leonid mentioned in his answer to my first linked question. In that same answer, he alluded to other, "advanced," uses of Block. I was thinking there would be something clever, like the use of Module for defining functions. – VF1 Oct 4 '12 at 23:04
• @VF1, they will all fall in temporarily clear definitions because that's what Block does. But there are very creative uses of temporarily clearing definitions, like the ones mentioned and others. They mentioned typical examples but when you get the hang of it, custom uses come naturally and you begin to feel that Module has nothing to do. Say you do a recursive function f[n_]:=f1[f2[f3[f4[f[n-1]]]]], it may be the case that by changing it to Block[{f}, f1... you delay f evaluation and get a less deep recursion stack. – Rojo Oct 5 '12 at 3:33
• That example and others may fall in the category of using Block to control the evaluation of inner parts of some code, without having to actually modify or mess with the internals. And, knowing there's a way to do that can open up doors on how you wish to design your own code – Rojo Oct 5 '12 at 3:35