*Extended comment*

First of all, I think there is no easy answer to this question.

Let me collect my examples in an answer, in order to provide some structure in them as well as not to flood the comments. Throughout the answer, the lines of text describing the code refer to the code below it.

You will find that the examples which reach `$IterationLimit`

are much harder to understand. If there is nothing mysterious about `x:={x}`

creating infinitely much work for the kernel, then there is also nothing mysterious about `x:=Identity[x]`

causing infinitely much work.

```
Clear[f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, x, x2, x3, x4, x5]
```

The following reaches `$RecursionLimit`

```
x2:=Identity@x2;x2
```

No infiniteness

```
x=x;x
y //. y :> y
```

Infinite iteration

```
x3:=Identity[Unevaluated[x3]]; x3
```

No infiniteness

```
y//.HoldPattern[y]:>Identity[Unevaluated[y]]
a[y] //. HoldPattern[y] :> Identity[Unevaluated[y]]
```

Infinite iterations

```
Hold[y] //. HoldPattern[y] :> Identity[Unevaluated[y]]
SetAttributes[b, HoldFirst]; SetAttributes[c,HoldRest]
b[y] //. HoldPattern[y] :> Identity[Unevaluated[y]]
b[y, 1] //. HoldPattern[y] :> Identity[Unevaluated[y]]
c[1, y] //. HoldPattern[y] :> Identity[Unevaluated[y]]
```

No infiniteness

```
b[1, y] //. HoldPattern[y] :> Identity[Unevaluated[y]]
c[y, 1] //. HoldPattern[y] :> Identity[Unevaluated[y]]
```

No infiniteness

```
p : f1[x_] := p; f1[1]
p : f2[x_] /; True := p; f2[1]
p : f3[x_] := p /; True; f3[1]
```

Infinite iterations

```
p : f4[x_] := Identity@Unevaluated@p; f4[1]
f5[g_] := g[g]; f5[f5]
f6[x_] := f6[x]; f6[1]
(p : f7)[x_] := p[x]; f7[1]
```

No infiniteness

```
f8[_] := f8[1]; f8[1]
f9[] := f9[]; f9[]
f10[___] := f10[]; f10[]
```

Infinite iteration

Combining the previous definitions, we do get an infinite iteration.

```
f11[] := f11[];
f11[___] := f11[];
f11[]
```

**Set vs SetDelayed**

II

```
f[x_] = f[x]
```

**Shortcut in action**

We can do

```
p : f12[_] /; (x5 = True) := p
f12[x5]
```

which outputs

```
f17[x5]
```

and does set x5. So we see that x5 that after the replacement the expression is not properly evaluated.

Related, but not understandable: Unexpected behaviour of Unevaluated

1

related to this answer: http://mathematica.stackexchange.com/a/39936/534

– becko – 2014-01-07T13:39:39.3431I guess Mathematica tries to be smart in some definitions with no patterns on the rhs and sometimes skips them after a couple of iterations in which the rhs didn't change upon evaluation. Let's see if someone digs in and shares a more exact mechanism as to when this happens and when it doesn't – Rojo – 2014-01-07T14:23:31.117

The general idea of my guess already would explain your examples.

`Identity[x]`

loops because it evaluates to something.`f[x_]:=f[x]`

loops because it's rhs has to be built every time, it has a pattern – Rojo – 2014-01-07T14:29:34.380@Rojo More precisely, there's a loop (in these examples) whenever

`ValueQ`

returns`True`

... I think... – becko – 2014-01-07T14:34:27.620@Rojo, interestingly

`p:f[x_] := p`

does not loop – Simon Woods – 2014-01-07T14:50:05.070@SimonWoods and now I add an exception for patterns that name the lhs as a whole, just to hide from the fact that my guess is clearly not right – Rojo – 2014-01-07T14:52:49.097

@SimonWoods In your example,

`ValueQ[f[x]]`

returns`False`

, so my guess (based on @Rojo's guess) that there's a loop whenever`ValueQ`

returns`True`

still applies. – becko – 2014-01-07T15:03:17.2275The Standard Evaluation Procedure "continue[s] reevaluating results until it gets an expression which remains unchanged through the evaluation procedure." So

`x = x`

is applied only once (no change);`x := Identity[x]`

leads to infinite recursion:`Identity[Identity[…]]`

because the argument`x`

is evaluated before`Identity[x]`

and becomes`Identity[x]`

, in which`x`

is evaluate before`Identity[x]`

, ad infinitum. (In other words, Jacob is basically right.) – Michael E2 – 2014-01-07T15:15:27.807`x := Identity[Unevaluated[x]]; x`

reaches iteration limit rather than recursion limit. That was really my point, thanks for reminding me :). – Jacob Akkerboom – 2014-01-07T15:28:52.6371@MichaelE2 how would that explain

`f[x_]:=f[x]`

giving an infinite iteration? – Rojo – 2014-01-07T15:34:01.533I would say that the difference is because the semantics of function calls supports recursion, but the semantics of atom evaluation does not. But does this explain the issue or just kick the issue down the road? Depends on how deep an explanation is being asked for, doesn't it? – m_goldberg – 2014-01-07T15:55:23.000

@m_goldberg I would like an explanation that starts from the evaluation mechanism of Mathematica. There should be a general principle (I hope) that establishes when there is infinite recursion and when there isn't. – becko – 2014-01-07T16:12:39.857

4@Rojo As you know

`f[x_] := f[x]`

has nothing to do with`Global`x`

, so let's use`y`

in`f[y]`

. I think difference is in how pattern replacements are handled. When`f[y]`

is evaluated,Mevaluates the head`f`

first, finds the downvalue, applies it. Now, to apply it,Mneeds to evaluate the rhs,`f`

of the pattern`x`

. After it does the substitution, the result has not been evaluated yet. So even though the result is again`f[y]`

,`f[y]`

has to be evaluated once more. Clearly you want this to happen for normal functions. Here you get infinite recursion. – Michael E2 – 2014-01-07T16:33:52.947@Michael E2, I came to the same conclusion a while ago, but I couldn't explain that

`ff[y] //. ff[x_] :> ff[x]`

does not give an infinite recursion. How would you explain that? If you really think that calling a function is just replacement by Own/Down/Up/Sub-values, this is challenging. – Jacob Akkerboom – 2014-01-07T17:24:55.0872@JacobAkkerboom I think

`ReplaceRepeated`

examines the result of a replacement after evaluation is complete and continues until a fixed point is reached. After the first replacement, the expression is the same as the starting expression, so it stops. – Michael E2 – 2014-01-07T18:13:04.377@Rojo I think that the answer of Michael covers this case as well (

– Leonid Shifrin – 2014-01-07T23:31:42.967`f[x_]:=f[x]`

), if we recall that such a definition is tail-recursive, as I was describing here (tail recursion has been already mentioned in this discussion by Jacob). In that discussion, I mentioned that tail-recusrive functions in Mathematica are affected by`$IterationLimit`

rather than`$RecursionLimit`

, because they rewrite complete expressions and don't grow the expression stack.@LeonidShifrin. There's a simpler side to this question, the

`Identity`

example. But I understand the "hard" part of it: in what cases do you get an infinite loop and when you don't, when the expression being replaced isn't changed at all? After replacement it is always reevaluated, and the evaluation sequence starts over. But it doesn't really start over, because, sometimes, after the second evaluation of the same unchanged thing, it knows not to try again, and sometimes it doesn't and iterate infinately – Rojo – 2014-01-08T00:15:49.483@Rojo Re: general part - yes, I agree. Re:

`ClearAll[f];f[x_]:=f[2];f[x_]:=f[3];`

- actually, this one doesn't look mysterious to me, the second definition simply replaces the first, as it should. – Leonid Shifrin – 2014-01-08T09:55:49.030@LeonidShifrin Terrible example, sorry. I'll be deleting that comment. – Rojo – 2014-01-08T13:15:32.300

@LeonidShifrin Say

`f[x_] := f[2]; _f := 10`

. The second definition ends up matching, and from the docs I would expect it should always either match the first one or stop iterating because the result isn't changing. As happens with`//.`

– Rojo – 2014-01-08T13:18:52.567@Rojo

`_f:=10`

is so ugly :P (temporary message) – Jacob Akkerboom – 2014-01-09T10:27:59.820@Rojo the first one does match. It produces

`f[2]`

and on the second (maybe third depending on how you count) iteration the second one matches and yields`10`

. Evaluator won't apply the same rule on consecutive iterations if it keeps on yielding the same result, otherwise it won't be able to terminate. So for`f[1]`

we have evaluation sequence`f[1]`

->`f[2]`

->`f[2]`

(but result is discarded and rule is removed from consideration as same rule produced same result on consecutive iterations) ->`10`

. – Oleksandr R. – 2014-01-10T03:30:42.403@OleksandrR. I agree. That's why I think that means reality is not quite as explicitly documented. It does not continue evaluating until the result doesn't change. It sometimes changes how the evaluation is done so that the result is changed when it otherwise wouldn't. And it's not about iterating versus not iterating, but about deactivating one definition at a time – Rojo – 2014-01-10T04:55:02.783