# HoldPattern vs Unevaluated

For learning purposes I created this code:

{g, 3*(10 + g)} /. HoldPattern[Plus[t__]] :> (Plus[t] /. g -> h)


I am learning about HoldPattern. As I understand it HoldPattern makes sure that the pattern is not Evaluated. If this is the case however, then what is the difference with Unevaluated and why does Unevaluated not work in case of patterns?

• @Kuba, I guess my question is what the difference is between the two in the case of patterns – GambitSquared Aug 16 '17 at 13:07
• Will delete my previous comment as I am not sure I understood the question but I don't have time to focus now. Let me leave the old related link 112842 and another closer one: 110499 – Kuba Aug 16 '17 at 13:13
• This is the same as asking about the difference between Hold (or anything with a Hold* attribute) and Unevaluated. Google for this and you'll find several discussions (many point to the Villegas tutorial). Unevaluated gets stripped out in the first "evaluation step". Its argument will get evaluated during the second step. – Szabolcs Aug 16 '17 at 13:26
• Try Unevaluated[1 + 1], Unevaluated[1 + 1] + 1 and Hold[1 + 1] + 1 and TracePrint their evaluations. The first one is a special case because evaluation stops when Unevaluated[...] reach the top level. The second one evaluates to (1+1)+1 which then evaluates further immediately. – Szabolcs Aug 16 '17 at 13:28

HoldPattern is a persistent head that prevents evaluation of its argument(s) yet is transparent to pattern matching. Unevaluated is a temporary wrapper that prevents the evaluation of a single argument* by a single head at one point in the evaluation, and then is stripped. Once it is stripped it cannot have any further effect on the evaluation.

You can use Unevaluated in your example pattern, but it must wrap the entire rule rather than only the left hand side:

{g, 3*(10 + g)} /. Unevaluated[Plus[t__] :> {t}]    (* simplified RHS for clarity *)

{g, {30, 3 g}}


Unevaluated[Plus[t__]] :> {t} would not work even if Unevaluated acted normally(1) because it would only prevent RuleDelayed from evaluating Plus[t__] but the entire rule would be (re)evaluated by ReplaceAll and Plus[t__] reduced to t__.

* Although undocumented and even marked in red as a syntax error Unevaluated will accept multiple arguments, and when activated it effectively transforms into Sequence while simultaneously holding. This transformation takes place after the Sequence would be flattened in the normal evaluation procedure, so it remains as a single expression even if the head (f below) does not have SequenceHold or HoldAllComplete.

ClearAll[f]

f[x_] := HoldComplete[x]

f[Unevaluated[1 + 1, 2 + 2, 3 + 3]]

HoldComplete[Sequence[1 + 1, 2 + 2, 3 + 3]]


Observe that Sequence[1 + 1, 2 + 2, 3 + 3] is bound to the single parameter pattern x_, rather than becoming f[1 + 1, 2 + 2, 3 + 3] which would not match the definition given. In other words the behavior is the same as:

f[Unevaluated @ Sequence[1 + 1, 2 + 2, 3 + 3]]

• Excellent answer. No single word that is not needed, and yet a complete description. Your text is as terse yet functional, as your code. My hat is off. – Leonid Shifrin Aug 16 '17 at 21:23
• @Leonid I am sincerely flattered. – Mr.Wizard Aug 17 '17 at 4:44
• @Leonid I thought of something to add. Hopefully it is useful and does not detract too much from the pithiness of the answer. – Mr.Wizard Aug 17 '17 at 4:55
• “… because it would only prevent RuleDelayed from evaluating Plus[t__] but the entire rule would be (re)evaluated by ReplaceAll and Plus[t__] reduced to t__.” Maybe I missed something, but I think it's not true? Unevaluated[Plus[t__]] :> {t} will evaluate to t__ :> {t} even when it's outside of ReplaceAll. – xzczd Aug 17 '17 at 11:41
• @xzczd Right, that's what I meant by "even if Unevaluated acted normally" -- see the superscript link next to that phrase for a related discussion. Perhaps I can think of a better way to write that. – Mr.Wizard Aug 18 '17 at 18:42