Re: Re: problem writing debugging utility function

*To*: mathgroup at smc.vnet.net*Subject*: [mg100371] Re: [mg100308] Re: problem writing debugging utility function*From*: Leonid Shifrin <lshifr at gmail.com>*Date*: Tue, 2 Jun 2009 06:42:45 -0400 (EDT)*References*: <gvq09k$mqv$1@smc.vnet.net> <200905311037.GAA17048@smc.vnet.net>

Hi, Just to add some more to the reply of Szabolcs: The evaluation process in Mathematica is recursive, going first "down" to leaves, then evaluating it "up", starting from leaves and going to larger sub-expressions, checking for the global rules to match. Unevaluated is treated in a special way in that it suppresses the evaluation of expression "on the way down", allowing the rules attached to the head (say <g>) surrounding it to apply "on the way up" on the original expression. The original expression may or may not evaluate later, depending on what <g> does with its argument. In the following example: In[1] = g[x_ + y_] := x*y; g[Unevaluated[5 + 5]] Out[1] = 25, the rule attached to <g> did apply since the expression 5+5 was preserved in its unevaluated form. In this case, the original expression (Plus operator) never evaluated, but in some other cases it may evaluate - it all depends on <g> now. But without Unevaluated, <g> would never have a chance to see the original expression, since by the time evaluation goes "up" to g, 5+5 would have evaluated to 10 already. This situation indeed is precisely as if we would give <g> Hold attribute "on the way down" and remove it "on the way up". There are several differences between Hold and Unevaluated. Technically, Hold is just a wrapper with a HoldAll attribute which is not particularly different from any user-defined HoldAll wrapper, and is special just because it is the "official" holding wrapper and there are commands such as ReleaseHold that work with it together. Most of the functionality of Hold can pretty much be duplicated/reproduced by any HoldAll wrapper. OTOH, Unevaluated is one of the "magic symbols", along with Evaluate and Sequence. It is more deeply "wired in", into the main evaluation loop algorithm, and its functionality can not be removed, blocked or duplicated. In particular, we may block Hold with a Block trick Block[{Hold},...], but we can not block Unevaluated in the same way. Another difference is that (one level of wrapping with) Unevaluated does not by itself represent extra level of wrapping - it is automatically stripped off when the evaluator comes to apply the rules to expression inside it. Not so with Hold - it is a normal wrapper. >From the viewpoint of the user, the uses of Hold and Unevaluated are also different. Hold is often used to preserve the internal expression unevaluated for more than one successive evaluation (or in between such evaluations). For example, if one function (say <f>) produces the result as an expression which wil normally evaluate but whose evaluation we want to prevent, and another function (say <h>) needs to consume this result in this unevaluated form, but the result is not passed directly from <f> to <h>, then <f> may wrap the result in Hold and <h> will then have to unwrap it. Unevaluated would not help us here since it is normally used in a single evaluation. Here is a simple example: In[2] = Clear[f,h]; f[x_] := Module[{y}, y = Hold[x^2]]; h[x_Hold] := x /. Hold[a_^b_] :> {a, b} In[3] = odd = Select[f /@ Range[10], Not[FreeQ[#, _?OddQ]] &] Out[3] = {Hold[1^2], Hold[3^2], Hold[5^2], Hold[7^2], Hold[9^2]} In[4] = h /@ odd Out[4] = {{1, 2}, {3, 2}, {5, 2}, {7, 2}, {9, 2}} What happens here is that <f> constructs some power (square) while <h> deconstructs it to base-power pair. But <h> is not called directly on the result of <f>, so we need to prevent expressions from evaluation in between evaluations involving <f> and <h>. Unevaluated would not be helpful here. Another thing worth mentioning (and more directly relevant to your example) is the mechanics of argument - passing. Consider this function: In[5] = Clear[f]; f[x_] := {Hold[x],Head[x]}; It is supposed to return the held input together with its head . Let us try In[6] = (Print["Just before calling f"]; f[#]) &[Print["*"]] * Just before calling f Out[6]= {Hold[Null],Symbol} If we attempt to force it to not evaluate the argument (Printing), in this way: In[7] = Function[y, (Print["Just before calling f"]; f[y]), HoldAll][Print["*"]] Just before calling f * Out[7]= {Hold[Null],Symbol} We see that the result was indeed not evaluated before having been passed to <f>, but it was evaluated in <f>, and the r.h.s of <f> uses an already evaluated result. Now, it is to prevent also this evaluation of the argument that we need Unevaluated: In[8] = Function[y, (Print["Just before calling f"]; f[Unevaluated[y]]), HoldAll][Print["*"]] Just before calling f * Out[8] = {Hold[Print["*"]], Symbol} We see that the printing still takes place, and while the held part is ok, the head part still computes the Head of the evaluated argument (that's where the printing happens). This is because this time, Head needs Unevaluated - we redefine <f>: In[9] = Clear[f]; f[x_] := {Hold[x],Head[Unevaluated[x]]}; In[10] = Function[y, (Print["Just before calling f"]; f[Unevaluated[y]]), HoldAll][Print["*"]] Just before calling f Out[10]= {Hold[Print[*]],Print} Now we get what we want. Hopefully by this moment the pattern started to emerge. Note that Unevaluated is unnecessary if the function itself holds its argument, possessing one of the hold attributes: In[11]= ClearAll[f]; Attributes[f] = {HoldAll}; f[x_] := {Hold[x], Head[Unevaluated[x]]}; In[12] = Function[y, (Print["Just before calling f"]; f[y]), HoldAll][Print["*"]] Just before calling f Out[12]= {Hold[Print[*]],Print} It is slightly off the main line of the argument, but another common pitfall associated with this sort of things is something like this: In[13] = {Hold[#] &[5^2],Hold[5^2]} Out[13] = {Hold[25],Hold[5^2]} The #-& notation is so routinely used that one often forgets that it does introduce an additional parameter-passing stage. This is what one should use to avoid evaluation during that stage: In[14] = {Function[Null, Hold[#], HoldAll][5^2], Hold[5^2]} Out[14] = {Hold[5^2], Hold[5^2]} Sometimes the opposite is needed however: In[15]:= i = 0; Function[x, {x, x, x}, HoldAll][i++] Out[15]= {0, 1, 2} In[16] = i Out[16] = 3 In[17]:= i = 0; Function[x, {x, x, x][i++] Out[17]= {0, 0, 0} In[18] = i Out[18] = 1 In this case, chances are that the first behavior is not what was intended. So, to summarize: Hold is mostly useful to prevent evaluation of some results, in between some other evaluations. Unevaluated in useful to force some function use - just once, in this particular evaluation (for its r.h.s.) - its original (unevaluated) argument if that function does not have a corresponding hold attribute. Hold attributes are useful for the same thing, but 1) They are permanent, not just one-time use 2) Unevaluated wrappers are stripped off when evaluator meets them "on the way up", so subsequent evaluation uses already normal version of the argument - not so with attributes 3) You may need to work with functions written by others (or system functions), for which changing attributes even temporarily may have undesired/unpredictable consequences - in this case Unevaluated is more appropriate, to make up for the lacking hold attribute just once. Perhaps, another way to put is is that attributes belong to the function, while Unevaluated "belongs" to a particular argument (though affecting the execution of the function on that argument as if that function had a hold attribute). This is probably a very long-winded way to explain these things, but I hope it will still clarify some issues. Best regards, Leonid On Sun, May 31, 2009 at 3:37 AM, dabrowsa at indiana.edu <dabrowsa at indiana.edu>wrote: > Thanks a lot to Leonid, Szabolcs, and Ken for their solutions. I > liked Leonid's the best, being both much simpler and more general than > mine. > > SetAttributes[ShowIt, HoldAll]; > ShowIt[code_] := > Module[{y}, > Print[ToString[Unevaluated[code]], " = ", y = code]; > y]; > > My own solution was the hideous > > $PreRead=ReplaceAll[#,{{"dbgv","[",var_,"]"}:>{"Print","[",RowBox > [{"\""<>var<>" = "<>"\"",",",var}],"]"}}]&; > > which makes dbgv work like a macro. The grotesqueness is because what > $PreRead sees is a very raw input form, with expressions broken down > into RowBox's. In a sense this is the most direct analog to Lisp's > macros, but ... yechh. > > The Unevaluated[] function had slipped off my radar, probably because > I never fully grokked the distinction between it and Hold[]. In fact > I'm still a bit confused about it. At first I thought it might like > the evaluation inhibitor ` in Lisp, but some examples disabused me of > that. > > In[2]:= f@Unevaluated[5 + 6 + 7 + 8] > > Out[2]= f[Unevaluated[5 + 6 + 7 + 8]] > > In[11]:= ToString@Unevaluated[5 + 6 + 7 + 8] > > Out[11]= "5 + 6 + 7 + 8" > > > I might have expected Out[11]= "Unevaluated[5 + 6 + 7 + 8]" > > > In[13]:= sqr[x_] := x^2 > > In[14]:= sqr@Unevaluated[5 + 6 + 7 + 8] > > Out[14]= 676 > > > I might have expected Out[14]= sqr[5 + 6 + 7 + 8] since sqr does not > know what to do with the pattern _+_+_+_ or _+_ for that matter. > Could anyone elucidate this for me? >