Timeline for Module trash collection behaviour
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 16, 2013 at 6:01 | comment | added | Alexey Popkov |
Both questions are answered, thank you. Hold[2] /. 2 :> Block[{x = 3}, x /; True] gives Hold[3] but Hold[2] /. 2 :> Module[{x = 3}, x /; True] gives Hold[x$853]. It means that Module performs literally lexical scoping and no more, and Block performs dynamic scoping. I think such enlightening example must be in the Documentation!
|
|
| Nov 16, 2013 at 5:51 | comment | added | Rojo | @AlexeyPopkov I am not sure why that design choice was made but I wouldn't know why the opposite design choice should have been made, so I don't see it as a bug. | |
| Nov 16, 2013 at 5:49 | comment | added | Rojo |
@AlexeyPopkov 1) The Condition isn't evaluated outside of the Module. Condition is HoldAll. All it does, when immediately inside a Module on the rhs of a rule, is to check if it matches and, if it matches, then do the replacement unevaluated. Try Hold[2]/. 2:>Module[{x=2}, x/;True]
|
|
| Nov 16, 2013 at 5:44 | comment | added | Alexey Popkov |
Your explanation raises 2 questions: 1) If you are right and Condition is evaluated outside of the Module, isn't it a bug itself? 2) This explanation contradicts the workaround you suggest: if Condition is evaluated outside of Module, then it will be evaluated even with Block on the lhs (and this happens if one removes the /;True from Block).
|
|
| Nov 16, 2013 at 5:27 | history | answered | Rojo | CC BY-SA 3.0 |