Services & Resources / Wolfram Forums / MathGroup Archive

MathGroup Archive 2005

[Date Index] [Thread Index] [Author Index]

Search the Archive

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

  • To: mathgroup at smc.vnet.net
  • Subject: [mg56950] Re: [mg56939] Re: [mg56720] Re: [mg56696] named pattern variable scoped as global, should be local
  • From: Chris Chiasson <chris.chiasson at gmail.com>
  • Date: Wed, 11 May 2005 05:24:05 -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>
  • Reply-to: Chris Chiasson <chris.chiasson at gmail.com>
  • Sender: owner-wri-mathgroup at wolfram.com
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: [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
> >
> >
> 
> 


-- 
Chris Chiasson
http://chrischiasson.com/
1 (810) 265-3161
  • Prev by Date: Re: Representation and Simulation of Dynamic Systems
  • Next by Date: Re: Re: Mathematica Notebook Organiztion
  • Previous by thread: Re: Re: named pattern variable scoped as global, should be local
  • Next by thread: Re: Re: Re: Re: named pattern variable scoped as global, should be local