Re: Re: Re: scope all wrong? in Mathematica 4.1

*To*: mathgroup at smc.vnet.net*Subject*: [mg31947] Re: [mg31914] Re: Re: scope all wrong? in Mathematica 4.1*From*: David Withoff <withoff at wolfram.com>*Date*: Thu, 13 Dec 2001 01:08:56 -0500 (EST)*Sender*: owner-wri-mathgroup at wolfram.com

> I think that ideal behavior would be to issue a warning "argument of > function is shadowed by local variable, will have no effect" I would go along with that. Probably the only objection would be that adding such a message may not be worth the effort, since essentially no on ever makes this mistake anyway. I found the next comment to be fairly interesting: > To barge right in and replace x in the body of the Module when > this x should refer to the local variable strikes me as too simplistic and > is therefore a surprise. Does this mean that the behavior was surprising because it wasn't sufficiently complicated? The only times that I have been confused by Mathematica was when I expected it to be more complicated than it really was. Mathematica is actually a pretty simple system. The two different ways of handling this situation can be illustrated by comparing: In[1]:= f[x_]:=Module[{x},x=5;Print["x is ", x]] In[2]:= f[99] Module::lvsym: Local variable specification {99} contains 99 which is not a symbol or an assignment to a symbol. Out[2]= Module[{99},99=5;Print[x is ,99]] where, as you noted, the value associated with x in f[x_] just goes barging right in to the right side of the rule, and In[3]:= f = Function[{x},Module[{x},x=5;Print["x is ",x]]]; In[4]:= f[99] x is 5 where the value associated with the x in Function[{x}, ...] respects the local variable of same name in the Module. So there really are two qualitatively different ways of handling this situation. The decision on how to handle this in Mathematica was not made lightly. Among the many considerations was the observation that most people think of applying a rule as a qualitatively different operation than evaluation of nested scoping constructs, and in particular expect things like With[{x = 99}, Module[{x}, ...]] to be handled differently than things like f[99] /. f[x_] :> Module[{x}, ...]. People who expect rule application to be handled like another scoping construct may very well be disappointed by this design choice. I'm not sure it is possible to design a programming language that matches everyone's expectations. I would claim, however, that there is ample precedent in other programming languages for this aspect of the design of Mathematica, that there is no absolute principle for choosing one design or the other, and that in some sense it comes down to choosing what will be most useful to most users most of the time. > I tried in my previous post to express what I think would have to be > changed to accommodate "ideal" behavior. In essence, some processing (and > therefore unHolding) of the RHS of := -- to determine the locals and look > for name clashes, and if neccessary preempt the pattern matcher -- would > have to occur before the value that the system has determined for the > pattern x_ on LHS is passed in to the RHS. Currently, this passing is > essentially instantaneous. Yes, that is the other possibility (e.g. the behavior of the second example above). Things could certainly be done that. It is obviously debatable, of course, that this alternative is "ideal". > 2) My comment about the local x$9 reemerging as a de facto global (growing > wings as it were and flying the coop) does seem relevant to Fateman's > concern about scope violation and "escaping" variables. Variables like x$9 > are normally off-limits to programmers outside of the subroutine in which > they are declared as local. Does Mathematica rely on the uniqueness of x$n > variable names to keep track internally of multiple versions of global rules > generated programmatically inside a Module, by using them in effect as part > of their "signature"? I know that I can change rules after the fact (i.e., > after the scope of x$n as originally declared in its subroutine has > disappeared) by changing the x$n to which they have been "hard-wired". Of > course, no one who has used Mathematica entertains for a moment the > possibility that local variables are escaping wholesale -- this would make > Mathematica completely unusable, whereas in practice it's eminently usable > (albeit with a steep learning curve). But the observed phenomenon does seem > to be a kind of "back door" and therefore not exactly kosher... This is an observation about an implementational detail, rather than anything fundamental about the language. Values of local variables are essentially always accessible in any programming system. In typical C or Fortran implementations, for example, you can inspect or modify values of arbitrary local variables by using system-dependent commands to determine the corresponding memory locations. The only difference is that, in Mathematica, those variables are more accessible. In Mathematica you can do it by finding the right sym$nnn variable (analogous to finding the right memory location in other systems) and then using ordinary evaluation or assignment (analogous to using memory "peek" and "poke" functions in other systems). So that "back door" exists in any system. A lot of people rather like the accessibility of these private variables, especially for debugging purposes. It would be possible to make them more well hidden in Mathematica by removing them from the symbol table, but I hope that that doesn't happen. There is a fairly clear statement in the documentation not to mess with these variables unless you know what these variables are doing and you have a good reason to mess with them. > PS. I think for clarity it would be best to include a code snippet showing > exactly what I mean here. > Here's a greatly abridged example from actual code: > > \!\(\(\(setRules[sym_: D, \ delayCircleDotEvaluation_: 0]\ := \ > Module[{\ h, \ symL}, \[IndentingNewLine]If[Head[sym]\ =!= \ List, \ > symL\ = \ {sym}, \ > symL\ = \ sym]; \[IndentingNewLine]SetAttributes[ > SmallCircle, {OneIdentity, \ > Flat}]; \[IndentingNewLine]a_\ \[SmallCircle]\ b_\ /; \ > Head[a] === Plus\ || \ Head[b] === Plus := \ > Distribute[h[a, \ b]]\ /. > h -> SmallCircle\ ; \ \[IndentingNewLine]\((a_. \ S_\_u_)\)\ \ > \[SmallCircle]\ \((b_\ \ c_)\)\ := \ > a\ b\ \ S\_u\ \[SmallCircle]\ c\ + \ > a\ S\_u\ \[CircleDot]\ b\ c\ /; \ > MemberQ[symL, \ > S]\ \ && \((FreeAllQ[b, symL]\ || \ > Head[b] === > > CircleDot)\);\[IndentingNewLine]];\)\(\[IndentingNewLine]\ > \) > \)\) > > If you run setRules and then do DownValues[\[SmallCircle], pick out the > rule involving S, and do a FullForm, you will not find S but rather symL$n > instead (its value is in fact that of S, but it is being held; Cases[rule, > symL$n, {0, Infinity}] returns {}). If you change symL$n interactively, > you will change rule accordingly. (But I thought symL$n was local! So this > really is a back door.) Since I don't know what "run setRules" means (evaluate SetRules[] perhaps?) or what "do DownValues[\[SmallCircle]" means (DownValues[\[SmallCircle]] is a syntax error), and I don't know what this function is supposed to do, I can't comment on this example exactly, but I am guessing that the problem is with arguments that are held unevaluated and has nothing to do with variable localization. I am guessing, for example, that Module could be dropped from this example and it still wouldn't do what was intended. That problem can be corrected too, but it is separate issue. > A side observation possibly of interest: If we change the code in setRules > so that S is not first copied to symL (i.e., not "mediated") but used > directly in the rule, the value of S does appear when the rule is examined > using DownValues. This seems to shed some light on Mathematica's timing -- > the value found for S_ is passed to RHS of := very early and is not held but > treated as "raw". I don't understand exactly what this example is either (did you perhaps mean sym used directly, rather than S?), but if that guess is correct then yes, rule application is a way of getting values into held expressions and into scoping contructs like SetDelayed, both of which appear to be needed here. Dave Withoff Wolfram Research

**numerical approximation to the diffusion equation in Mathematica?**

**normalizationFourier[]**

**Re: Re: scope all wrong? in Mathematica 4.1**

**Re: Re: Path finding in graph theory, Lookig for your help**