It is not completely clear to me how Return[] works.

The documentation says:

Return[expr] returns the value expr from a function.

But in Mathematica it is not clear where are the boundaries of a "function" defined using patterns and Set(Delayed). The system simply applies replacement rules until there's nothing to change anymore.

Consider these examples:

a := (Module[{}, Return[0]; 1]; 2)    
(* 0 *)

It is not completely clear to me why Return breaks out from a, and not from Module or one of the CompoundExpression.

The following doesn't work, and simply returns the Return expression. It reminds me a bit of how Unevaluated is handled.

(Module[{}, Return[0]; 1]; 2)
(* Return[0] *)

If we add another layer of definitions, the effect of Return will stop there:

b := (a; 3)
(* 3 *)

Why do these three inputs give different results? What is the general rule for deciding where Return breaks out to precisely?

The answer lies somewhere in fully understanding the evaluation process.

Would someone care to elucidate this point, perhaps with pointers to the parts of the documentation which make this clear?

  • 4
    $\begingroup$ Be aware that the behavior of Return has changed from one version to another. I usually try to avoid using it myself. $\endgroup$
    – Mr.Wizard
    Dec 16, 2011 at 14:19
  • 2
    $\begingroup$ @Mr.W Wow, if its behaviour changes even between minor versions, than indeed it's better avoided! $\endgroup$
    – Szabolcs
    Dec 16, 2011 at 14:24
  • 2
    $\begingroup$ @Mr.Wizard, Szabolcs Personally I don't consider this particular observation as a strong evidence against using Return, since it is just the addition of new functionality (Fold), and no old code is broken (see also my commens below my answer). $\endgroup$ Dec 16, 2011 at 15:20
  • 1
    $\begingroup$ @Leonid I seem to recall at least one other case, on Mathgroup I suppose, where Return behaved differently per version. Does that sound unfamiliar to you? Also, I haven't given this a lot of thought but couldn't the change re: Fold break existing v7 code? It would probably be an odd use of Return, but not as odd a mutable PatternTest functions... ;-) $\endgroup$
    – Mr.Wizard
    Dec 16, 2011 at 15:33
  • 1
    $\begingroup$ @Mr.Wizard Well I guess one can construct an example of code that would be "broken" in a new version, but I have a hard time imagining that it would be less perverse than the method you mentioned (which, actually, I did use constructively several times). $\endgroup$ Dec 16, 2011 at 16:31

1 Answer 1


The exhaustive answer to this has been given in this thread (if you combine several answers there. The mentioned thread is also a generally recommended read for more information on this - at least one I am aware of). I will first reproduce here those bits of my answer from there which were correct.

There are two possible outcomes for any expression wrapped in Return: either it is inside some lexical (or dynamic) scoping construct for which the action of Return is defined - and then the presence of Return will lead to breaking-out-of-the-scoping-construct procedure, or it is not and then it is just a symbolic expression like any other. After breaking out of the scoping costruct (or just evaluation if it was not inside any scoping construct), Return gets discarded only if it was called from within the r.h.s. of a user-defined rule. Here is an example:


Out[1]= Return[a] 

In[2]:= b:=(Return[a];3) 
In[3]:= b 
Out[3]= a 

This behavior can be explained by consulting the exact rules of the evaluation procedure. Lacking a more up-to-date account, I cite here David Withoff's "Mathematica internals" of 1992: The very last step of the evaluation loop is (Chapter 3 - evaluation, p. 7, on the bottom): "Discard the head Return, if present, for expressions generated through application of user-defined rules."

Thus, when you use SetDelayed, you create a user-defined delayed rule and then Return is discarded, while for "direct" evaluation like

In[4]:= Return[a] 
Out[4]= Return[a] 

it is not. But, in


Out[7]= c 

it is, and Return is discarded, even though there was no scoping construct to break out of. The same happens in your example where Module is wrapped around - Return breaks out of Module all right, but is not discarded since Module was not the r.h.s of any user-defined rule.

Here are the best descriptions of how Return works that I am aware of, due to Alan Hayes (can be found in this MathGroup thread) :

"In view of the recent thread on Holding Arguments in a Second Argument List the following notes on Return may be of interest:

  • If Return[x] is generated as a value in Do or Scan then x is immediately returned;

  • If Return[x] is generated as an entry in CompoundExpression or as a value of the body of a While or For loop then Return[x] (not x) is immediately returned;

  • If Return[x] is generated as the value of a user-defined function then the function returns x (not Return[x])

  • Otherwise Return[x] behaves as a ordinary expression. "

These "empirical" rules agree with the statement found in the Withoff's report, the latter making the former sound somewhat less magical.

It is also good to remember that Return has a second optional argument, which tells it from which surrounding scoping construct to break out:

In[242]:= (Module[{}, Return[0, CompoundExpression]]; 2)
Out[242]= 0


In[243]:= (Module[{}, (Return[0, CompoundExpression]; 0)]; 2)
Out[243]= 2

In your last example, the outer CompoundExpression defined in b in dynamically rather than lexically scoped (relative to the stuff defined in a), and therefore this won't work (in other words, your last result is also as expected).

  • 1
    $\begingroup$ Let me see if I got it right: 1. Module/Block/etc. do not modify the handling of Return (i.e. they're just the same as CompoundExpression: the rest of the CompoundExpression is ignored and Return[value] is returned immediately). 2. Do and Scan do behave specially, as they return value and not Return[value]. 3. Return[value] is always replaced by value if it is the result of the application of a delayed-type replacement rule (:=), but not in the case of a normal replacement rule (=) ... $\endgroup$
    – Szabolcs
    Dec 16, 2011 at 13:23
  • 2
    $\begingroup$ ... Another interesting point that I didn't expect is the difference between := and =. Try a := Return[0] and b = Return[0]. The two behave differently, but their OwnValues look exactly the same (both use :>). Information does show us if := or = was used in the definition though. I was not aware that there existed a difference in the handling of := and = even after the definition was made ... $\endgroup$
    – Szabolcs
    Dec 16, 2011 at 13:25
  • 1
    $\begingroup$ @Szabolcs Your comments do indicate that I did not put enough effort in my answer, which is true - I mostly compiled it the sources I knew :). Ok, for your first comment: all correct, but the reason for direct assignment is not that this is not a replacement rule, but that its r.h.s. was evaluated immediately and that evaluation was not caused by an existing replacement rule. Consider, for example: ClearAll[a, b, c];a = b;b = Return[c];a - you get plain c at the end, even though all rules were immediate - but here Return[c] from b was a result of evaluation of the rule for a $\endgroup$ Dec 16, 2011 at 13:35
  • 1
    $\begingroup$ Yes, you are right. For some reason I thought that after a = Return[0] evaluating a would return Return[0] which is not the case. It return 0. So there's no difference between := and = after the definition has been made after all. Some more comments on Return: 1. f[Return[0,f]] does not behave the same way as Module[{}, Return[0,Module]] (or Fold or apparently any other builtin from where it might make sense to break out). The second argument of Return is not documented in M8 though, so perhaps it deprecated. 2. Just a note that Return will return from a Dialog[] $\endgroup$
    – Szabolcs
    Dec 16, 2011 at 13:45
  • 1
    $\begingroup$ @Szabolcs Ok, so: First, it seems that Return with a second argument only works for certain enclosing functions, not just any arbitrary f. Second, while Return with two arguments isn't documented, it is unlikely to go away and is "semi-officially" endorsed (see e.g. stackoverflow.com/questions/7446032/…), so I'd consider it safe to use. Next: the case you constructed: x = Module[{}, Module[{}, While[True, Return[0]]; 1]; 2] - here it appears that Return breaks from both Module (it does), but the mechanism is .. $\endgroup$ Dec 16, 2011 at 14:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.