WOLFRAM

Services & Resources / Wolfram Forums / MathGroup Archive

MathGroup Archive 2005

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

Search the Archive

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

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
  • Prev by Date: Re: Re: Representation and Simulation of Dynamic Systems
  • Next by Date: Re: Representation and Simulation of Dynamic Systems
  • Previous by thread: Re: Re: Re: named pattern variable scoped as global, should be local
  • Next by thread: Re: named pattern variable scoped as global, should be local