## Another difference between Set and SetDelayed. Evaluation shortcut?

16

6

A little while ago I wondered why

f[x_] = f[x]


gives an infinite iteration. I ended up discovering the following difference in evaluation between Set and SetDelayed with Evaluate.

count = 0;
ClearAll @ a
a /; (count++ < 20) = {a}
a // OwnValues
count = 0;
a


Output

{{{{{{{{{{{{{{{{{{{{{a}}}}}}}}}}}}}}}}}}}}}
{HoldPattern[a /; count++ < 20] :> {a}}
{a}


and

count = 0;
ClearAll@b
b /; (count++ < 20) := Evaluate@{b}
b // OwnValues
count = 0;
b


Output

{HoldPattern[b /; count++ < 20] :> {b}}
{{{{{{{{{{{{{{{{{{{{b}}}}}}}}}}}}}}}}}}}}


Can somebody explain the difference? Can we say that there is an evaluation shortcut at work here?

Related

This is a follow up question: Strange results of definitions using OwnValues

Why x = x doesn't cause an infinite loop, but f[x_] := f[x] does?

Does Set vs. SetDelayed have any effect after the definition was done?

A nice tool I made says SetDelayed is not called in a usual way in the last example – Jacob Akkerboom – 2014-01-10T16:26:30.320

2Ah, I see now. Thanks @Rojo – Mr.Wizard – 2014-01-10T17:13:40.780

2It's another cache Update[] related mystery – Rojo – 2014-01-10T17:17:04.547

@Rojo I noticed the same thing myself. – Mr.Wizard – 2014-01-10T17:18:20.457

As to the second, there are several symbols that have special ways of being set. Perhaps through UpValues (or perhaps you like upcode better :P). Clearly the XValues are some of those. Perhaps, when they overloaded the SetDelayed versions, they forgot to return Null? – Rojo – 2014-01-10T17:22:38.333

@Rojo Now we are talking ;). I was also thinking that the evaluation of the examples where I set OwnValues involved up code for OwnValues. I am writing a new question about this right now. – Jacob Akkerboom – 2014-01-10T17:27:55.683

5

I thought to give a bit more insight into why Update is needed, as pointed out in the other answers. Its documentation says Update may be needed when a change in 1 symbol changes another via a condition test.

In Jacob's example, setting count = 0 changes the condition test outcome, and thus a or b on the LHS. Consequently, a or b on the RHS is supposed to change. However, RHS a equals the old LHS a, which was undefined because count>=20, and needs Update to be changed. RHS b behaves the same, but was not evaluated in SetDelayed because Evaluate occurs before SetDelayed, so count is unchanged, and RHS b evaluates to LHS b with count<20. If we now reset count=0, evaluating b will return {b}.

To illustrate, I modify the example to separate LHS and RHS. MMA is clever enough to automatically update LHS declared as a variable, so I have to make a function:

count=0;
ClearAll[LHS,RHS];
LHS[]/;(count++<20)={RHS};
RHS=Unevaluated@LHS[];

count=0;
RHS (* Equals LHS[] with count >= 20 *)

(* Tell Wolfram Language about changes affecting RHS which depends on LHS *)
Update@Unevaluated@LHS;
RHS


LHS[]

{{{{{{{{{{{{{{{{{{{{LHS[]}}}}}}}}}}}}}}}}}}}}

Thanks for your answer, this seems to make sense and seems to have the right ingredients, but I will have to look at the details to fully understand and to be able to accept. – Jacob Akkerboom – 2016-08-18T14:39:14.857

@Jacob Thanks for the interesting question. I'm learning stuff I never thought about before. I'm looking at the link on infinite evaluation and trying to piece out the intricacies.. – obsolesced – 2016-08-18T15:28:55.463

3

Extended comment. Also: If Rojo wants to post an answer, I can delete this

It seems Rojo was right, guessing that it had to do with Update.

count = 0;
ClearAll@a2
a2 /; (Update[Unevaluated@a2]; count++ < 20) = {a2}
a2 // OwnValues
count = 0;
a2


Output

{{{{{{{{{{{{{{{{{{{{{a2}}}}}}}}}}}}}}}}}}}}}
{HoldPattern[a2 /; (Update[Unevaluated[a2]]; count++ < 20)] :> {a2}}
{{{{{{{{{{{{{{{{{{{{a2}}}}}}}}}}}}}}}}}}}}


I think user obsolesced rightly pointed out why there is an additional pair of brackets in the first output. This is because there is already a pair of brackets on the right hand side of Set and {a2} is evaluated rather than a2.

1The number of braces is different because {a2} is output instead of a2. – obsolesced – 2016-08-17T09:39:48.700

2

Also an extended comment; using Update[] makes the first recursion behave as expected:

count = 0;
ClearAll@a
a /; (count++ < 20) = {a};
count = 0;
Update[]
a

{{{{{{{{{{{{{{{{{{{{a}}}}}}}}}}}}}}}}}}}}


Apparently the LHS condition is affected by the use of Set versus SetDelayed. Certainly worth more exploration, but for me that will have to wait.