Return to Answer

• Enforcing correct variable bindings and avoiding renamings for conflicting variables in nested scoping constructs

Here the automatic renaming mechanism kicks in and changes x to x$ on both sides of the Rule.

• Enforcing correct variable bindings and avoiding renamings for conflicting variables in nested scoping constructs

Here the automatic renaming mechanism kicks in and changes x to x$ on both sides of the Rule.

However until now I did not realize that this affected constructs without a Hold attribute. That is I knew that Module handles Function, SetDelayed, and RuleDelayed differently:

Until now I did not realize that this affected constructs without a Hold attribute. That is I knew that Module handles Function, SetDelayed, and RuleDelayed differently:

Leonid comments below that Set and Rule are still scoping constructs. I do not contest this and you will note that above a carefully avoided the term "scoping constructs" for this reason. As noted the difference is in the evaluation behavior controlled by hold attributes.

The existing default behavior leaves both the LHS and RHS x unchanged which in this case results in the RHS instance evaluating to the global value of x if it exists:

Leonid comments below that Set and Rule are still scoping constructs. I do not contest this. As noted the difference is in the evaluation behavior controlled by hold attributes.

The existing default behavior leaves both the LHS and RHS x unchanged in this case which results in the RHS instance evaluating to the global value of x if it exists: