The task sounds simple, give the tree plot of 1+1. However, after some trying, I can only make this possible by using two Unevaluated.


TreeForm Plot

Since Head@Unevaluate[1+1] gives Plus, as expected, my first guess is that one Unevaluated is enough, however


gives 2.

Looks like somehow the front-end evaluates 1+1 again during the plot.

So my question is how to understand this behavior? Or are there any other conceptually correct ways to do the plot?

  • $\begingroup$ Unevaluated is a function I never truly understand… $\endgroup$
    – xzczd
    Mar 19, 2016 at 12:08
  • 1
    $\begingroup$ @xzczd You can find the explanation of Wagner's on P192. or here. However, even after reading these, the behavior I discribed really beats me. $\endgroup$
    – luyuwuli
    Mar 19, 2016 at 12:12
  • $\begingroup$ TreeForm@Inactive[Plus][1, 1] $\endgroup$
    – yode
    Mar 19, 2016 at 12:14
  • 2
    $\begingroup$ To me, this seems a defect in TreeForm. Have a look here for a previous discussion on this matter. $\endgroup$ Mar 19, 2016 at 13:17
  • 2
    $\begingroup$ TreeForm@HoldForm[Plus][1, 1] $\endgroup$
    – Bob Hanlon
    Mar 19, 2016 at 14:12

1 Answer 1


This issue is known and it is a defect of TreeForm like Leonid already said. Let me give an illustrative example that shows the same behavior. Let us assume you want a function that just returns its input unevaluated.

Without thinking we put down the function

f1[arg_] := HoldForm[arg]

Now, what seems like a clever idea has one flaw: when you evaluate f1[1+1] the 1+1 is already evaluated before f1 is called, because this is how the standard evaluation in Mathematica works. It evaluates all arguments of a function. Let us look at the Trace:

(* {{1+1,2},f1[2],2} *)

You see, the 1+1 is turned into 2 and after that, f1 is called. There is no chance your HoldForm could do anything useful.

But now you say, I can prevent exactly this evaluation by using Unevaluated. This is by the way the use-case for Unevaluated: You want to stop the evaluation of an argument to make that it reaches the body of your function unharmed:

(* {f1[1+1],1+1} *)

Perfect. But let's assume you rather want to turn your expression into a String instead of returning it with HoldForm. No problem you will say, because now you know how it works:

f2[arg_] := ToString[arg]
(* 2 *)

You don't have to think hard why this doesn't work when you have read carefully up to here. On every function call, the arguments are evaluated if this evaluation was not prevented by something. Let us look at the trace:

(* {f2[1+1],ToString[1+1],{1+1,2},ToString[2],2} *)

You see the 1+1 makes it unharmed to ToString but gets evaluated before ToString does its action. How could we prevent this? We could wrap another layer of Unevaluated around our expression:

(* {f2[Unevaluated[1+1]],ToString[Unevaluated[1+1]],ToString[1+1],1 + 1} *)

The first Unevaluated brings our expression unharmed inside f2, the second Unevaluated makes it survive the call of ToString.

Something similar happens in TreeForm and it is the reason, why a double Unevaluated works.

The final question

Why did f1 work then? There, the one Unevaluated should be eaten by the f1 call and HoldForm should evaluate 1+1 just like ToString did.

Exactly, instead of it doesn't because it has another way to say I don't evaluate my arguments.

(* {HoldAll,Protected} *)

The function HoldForm has the attribute HoldAll which says: "I don't evaluate any of my arguments". And it is true, if you think about it with your knowledge now, the only reason why this

In[22]:= HoldForm[1+1]
Out[22]= 1+1

returns 1+1, has to be something special about HoldForm. Therefore, here comes a third function that concludes the explanation:

(* 1 + 1 *)
  • $\begingroup$ It is not easy to prevent evaluation inside a function that has the attribute HoldAll. For example : SetAttributes[f3, {HoldAll}]; f3[arg_] := ToString[Unevaluated[#]] & @ arg; f3[1 + 1] gives 2. That is to say f[x] and f[#]& @ x have different behaviours. $\endgroup$
    – andre314
    Mar 19, 2016 at 20:23
  • $\begingroup$ Exactly and why is that? Because #& is another function that is called and that leaks evaluation! Look here. In general, Leonid has a bunch of very advanced answers around the topic evaluation control, but they might be a bit too difficult for beginners. This is why I wrote up an answer to this question, because it gave me the opportunity to discuss a very small detail that might lead to people thinking about this topic. $\endgroup$
    – halirutan
    Mar 19, 2016 at 20:34
  • $\begingroup$ AFAK, front-end is responsible for these formatting stuff. So it's a bug of the front-end? $\endgroup$
    – luyuwuli
    Mar 20, 2016 at 4:16
  • 1
    $\begingroup$ It's not entirely clear. On the one hand, if you use a LinkSnooper to monitor the communication between FronEnd and Kernel, you clearly see that the kernel sends the wrong result back. On the other hand, if you use math in a terminal session, you can call TreeFrom[Unevaluated[1+1]] and it gives you back a tree-form where the 1+1 is not evaluated. But the Unevaluated isn't stripped either. Therefore, I think the issue is in the kernel, but the kernel behaves differently when it is attached to a graphical FrontEnd. $\endgroup$
    – halirutan
    Mar 20, 2016 at 4:28
  • $\begingroup$ @halirutan Thanks a lot, I get it, and I'm sorry for my late reply. I wasn't informed by your comment. $\endgroup$
    – luyuwuli
    Mar 24, 2016 at 5:05

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.