Re: Re: named pattern variable scoped as global, should be local
- To: mathgroup at smc.vnet.net
- Subject: [mg56939] Re: [mg56720] Re: [mg56696] named pattern variable scoped as global, should be local
- From: "Fred Simons" <f.h.simons at tue.nl>
- Date: Tue, 10 May 2005 03:43:07 -0400 (EDT)
- References: <200505040433.AAA06165@smc.vnet.net> <200505051001.GAA21799@smc.vnet.net> <000a01c552ff$474046a0$84d19b83@pc5> <2ae120b5ba51383d5749e6263ef3d143@mimuw.edu.pl>
- Sender: owner-wri-mathgroup at wolfram.com
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: [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
>
>
- Follow-Ups:
- Re: Re: Re: named pattern variable scoped as global, should be local
- From: Chris Chiasson <chris.chiasson@gmail.com>
- Re: Re: Re: named pattern variable scoped as global, should be local
- 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>
- named pattern variable scoped as global, should be local