Re: Localize Pattern variables
- To: mathgroup at smc.vnet.net
- Subject: [mg107173] Re: Localize Pattern variables
- From: Szabolcs HorvÃt <szhorvat at gmail.com>
- Date: Fri, 5 Feb 2010 03:18:31 -0500 (EST)
- References: <hkeb04$t7v$1@smc.vnet.net> <4B6AB3AA.1080805@gmail.com>
2010/2/4 Istv=C3=A1n Zachar <replicatorzed at gmail.com>:
> Yes, I'm aware of that it is the job for RuleDelayed, but still I'm somewhat
> confused by:
> 1. why RuleDelayed localizes but not Rule; and
RuleDelay does not localize. It just prevents evaluation of the rhs.
Suppose r = 1. When r_ -> r + 1 gets evaluated, the result is r_ ->
2. The replacement rule that gets used by Replace & friends will be
r_ -> 2, and not r_ -> r + 1. RuleDelay will simply prevent the
evaluation is the rhs because it has the HoldRest attribute.
> 2. why does it work with Rule (except the interference thing)
> So I can ask the same: if it work's with Rule, why to use RuleDelayed
> (assuming that there is no interference)?
I do not understand this question. Can you clarify? What works with Rule?
If r has no value then there is no reason to use RuleDelayed in place
of Rule, but there is always a chance that one might assign a value to
it later, breaking functions ...
Regarding Module:
The fact that the following code produces 2 (and not x+1) is rather
confusing in my opinion, and I do not quite understand why it happens.
r = 1
Module[{r},
x /. r_ -> r + 1
]
Rule[] somehow interferes with Module's renaming scheme... If this is
indeed the intentional behaviour, and not a bug, then I think being
familiar with it is way beyond what can be expected from most users
... I was aware that Rule can affect scoping, but thinking back, I
have used code like the one above several times in the past, without
knowing that it was prone to being broken by setting values to global
variables ... At least the front end should colour that 'r' in red
(which indicates a conflict), not turquoise (which indicates
localization).
>
> Well, I guess, the answer for Q1 is: That's the way it is.
> But still Q2 leaves me wondering: why Rule works like RuleDelayed?
>
> Istvan
>
> Szabolcs Horv=C3=A1t wrote:
>>
>> On 2010.02.04. 12:28, Istv=C3=A1n wrote:
>>>
>>> Dear Group,
>>>
>>> I often write small replacement codes inside (packaged) functions. One
>>> toy model is like this:
>>>
>>> In[78]:= func[x_List] := ReplaceAll[x, r_Integer -> =C2 r + 100];=
r =.;
>>> func@{1, 2, 3, 4}
>>>
>>> Out[80]= {101, 102, 103, 104}
>>>
>>> In[81]:= r = -100; func@{1, 2, 3, 4}
>>>
>>> Out[82]= {0, 0, 0, 0}
>>>
>>> What is the best way to localize r in unc? Obviously modularizing it
>>> won't solve the matter:
>>>
>>> func[x_List] := Module[{r}, ReplaceAll[x, r_Integer -> =C2 r + 100]=
];
>>>
>>> produces the very same output. I can also use Block, instead of
>>> Module, which seemingly works, but then consider this version, where r
>>> interferes with an in-Block variable of the same name:
>>>
>>> func[x_List] := Block[{r}, r = 12; ReplaceAll[x, r_Integer -> =C2=
r +
>>> 100]];
>>>
>>> Of course I can always use RuleDelayed, but what if I don't want to.
>>> The embarrassing thing is that I'm pretty sure that before code
>>> colouring (v6), I missed this intereference quite a few times,
>>> assuming that lhs pattern variables are automatically bound with rhs
>>> ones, with a higher priority than assigning the value of existing
>>> variables of the same name to rhs pattern variables.
>>>
>>> How can I restrict (i.e. localize) non-delayed pattern variables to
>>> rules? Why RuleDelayed makes r local but not Rule? Am I missing
>>> something? Is there a general way to deal with this matter?
>>
>> Do you have a reasonable motive for not 'wanting' to use RuleDelayed? Th=
is
>> is the exact purpose of RuleDelayed. =C2 It evaluates the rhs after, n=
ot before
>> the replacement.
>>
>
- Follow-Ups:
- Re: Re: Localize Pattern variables
- From: Daniel Lichtblau <danl@wolfram.com>
- Re: Re: Localize Pattern variables