Re: Re: Re: Re: named pattern variable scoped as global, should be local

*To*: mathgroup at smc.vnet.net*Subject*: [mg57013] Re: [mg56950] Re: [mg56939] Re: [mg56720] Re: [mg56696] named pattern variable scoped as global, should be local*From*: DrBob <drbob at bigfoot.com>*Date*: Thu, 12 May 2005 02:33:34 -0400 (EDT)*References*: <200505040433.AAA06165@smc.vnet.net> <200505051001.GAA21799@smc.vnet.net> <000a01c552ff$474046a0$84d19b83@pc5> <2ae120b5ba51383d5749e6263ef3d143@mimuw.edu.pl> <200505100743.DAA08426@smc.vnet.net> <200505110924.FAA23984@smc.vnet.net>*Reply-to*: drbob at bigfoot.com*Sender*: owner-wri-mathgroup at wolfram.com

Trial and error is often the rule, I must agree. MOST of the time, though, I avoid the tricky cases without noticing. Bobby On Wed, 11 May 2005 05:24:05 -0400 (EDT), Chris Chiasson <chris.chiasson at gmail.com> wrote: > One day, I will understand why people don't understand or disagree > with what happens when using Block vs. Module. Until then, I'll just > have to be satisfied with bumbling around until my code works. > > On 5/10/05, Fred Simons <f.h.simons at tue.nl> wrote: >> Andrzej, >> >> I never thought of defining what a bug is. But whatever it is, it is at the >> and of the scale of undesirable behaviour. I agree that sometimes some >> undesirable behaviour is unavoidable and therefore cannot always be >> considered as a bug. Nevertheless the task of the programmer is to avoid >> undesirable behaviour as much as possible. >> >> Unfortunately, my analysis of of the curious behaviour of substitution rules >> in modules was not quite correct. I will present a simpler (and I hope >> better) one here. That also changed my opinion: now I am inclined to >> consider this behaviour as a bug. >> >> I added one extra command to the examples discussed so far: >> >> In[96]:= >> Clear[x, y, z]; >> x = 7; >> (* 1 *) z /. x_ -> 2*x >> (* 2 *) Block[{x}, z /. x_ -> 2*x] >> (* 3 *) Module[{x}, z /. x_ -> 2*x] >> y = 1; >> (* 4 *) Module[{x}, z /. x_ -> 2*x*y] >> (* 5 *) Module[{x, y = 1}, z /. x_ -> 2*x*y] >> >> Out[98]=14 >> >> Out[99]=2 z >> >> Out[100]=14 >> >> Out[102]=14 >> >> Out[103]=2 z >> >> It is strange that the results 2 and 3 are different, as are the results 4 >> and 5. >> >> Let us start with reading the manual, which is always a good start. It >> states: >> >> When nested scoping constructs are evaluated, new symbols are automatically >> generated in the inner scoping constructs so as to avoid name conflicts with >> symbols in outer scoping constructs. In general, symbols with names of the >> form xxx are renamed xxx$. >> >> The following command shows this renaming. Observe that Block is not a >> scoping construct, so the local variables in Block are not renamed. >> >> Module[{t}, Hold[{x, t, Module[{x}, x + t + v] , Block[{x}, x + t + v], >> Rule[x_, x + t + v], f[x_] := x + t + v, Function[{x}, x + t + v]}]] >> >> The manual does not exclude the situation that a local name in the inner >> scoping construct equals a local name in the outer scoping construct. We do >> an experiment: >> >> In[105]:= >> Module[{s, t}, Hold[{Module[{t}, x + t] , Module[{t}, s + t], Rule[t_, x + >> t], Rule[t_, s + t], f[t_] := x + t, f[t_] := s + t}]] >> >> Out[105]= >> Hold[{Module[{t}, x + t], Module[{t$}, s$19 + t$], t_ -> x + t, t$_ -> s$19 >> + t$, f[t_] := x + t, f[t$_] := s$19 + t$}] >> >> A local name in an inner scoping construct that equals a local name of an >> outer scoping construct seems to be renamed only when in the in the inner >> scoping construct another local name from the outer scoping construct >> occurs. >> >> I am wondering whether this indeed is intentionally. The manual suggests >> that renaming always takes place. Anyway, the undesirable results in the >> situations 3 and 4 are both due to the fact that the local variable x in the >> rule is not renamed to x$, as in situation 5. So now I am inclined to >> consider >> this behaviour as a bug. >> >> Fred Simons >> Eindhoven University of Technology >> >> ----- Original Message ----- >> From: "Andrzej Kozlowski" <akoz at mimuw.edu.pl> To: mathgroup at smc.vnet.net >> Subject: [mg57013] [mg56950] [mg56939] Re: [mg56720] Re: [mg56696] named pattern variable scoped as >> global, should be local >> >> > *This message was transferred with a trial version of CommuniGate(tm) Pro* >> > Fred, >> > >> > As usual very good and convincing analysis. As for whether this behaviour >> > constitutes a "bug" or not: I think this is probably one of those cases >> > that only the person who wrote the code can give the true answer. It seems >> > to me reasonable to define a bug as something in the code that causes >> > behaviour that is undesirable in a way that either not realised by the >> > programmer or could not have been avoided without causing even more >> > undesirable behaviour (this latter situation is quite common in programs >> > like Mathematica). I am now also inclined to think that under the above >> > definition this probably does not qualify as a bug. It seems to me that >> > this behaviour is mildly undesirable and causes some difficulty to users, >> > but probably it is a side effect of something intentional. Still, I do not >> > see any obvious benefits form $ not being appended when the RHS contains >> > unscoped variables; maybe this improves performance but the gain seems to >> > be very slight. Perhaps the reason lies in trying to be consistent with >> > some more general principles of scoping. >> > Unfortunately these "principles" do not appear to be clearly stated >> > anywhere, which of course is one reason why "detective work" like yours is >> > so valuable (as well as entertaining). >> > >> > Andrzej >> > >> > >> >> > > -- DrBob at bigfoot.com

**References**:**named pattern variable scoped as global, should be local***From:*leenewman@gmail.com

**Re: named pattern variable scoped as global, should be local***From:*Andrzej Kozlowski <akoz@mimuw.edu.pl>

**Re: Re: named pattern variable scoped as global, should be local***From:*"Fred Simons" <f.h.simons@tue.nl>

**Re: Re: Re: named pattern variable scoped as global, should be local***From:*Chris Chiasson <chris.chiasson@gmail.com>

**Re: Re: Representation and Simulation of Dynamic Systems**

**Re: Representation and Simulation of Dynamic Systems**

**Re: Re: Re: named pattern variable scoped as global, should be local**

**Re: named pattern variable scoped as global, should be local**