Skip to main content
40 events
when toggle format what by license comment
May 23, 2017 at 12:35 history edited CommunityBot
replaced http://stackoverflow.com/ with https://stackoverflow.com/
Apr 13, 2017 at 12:55 history edited CommunityBot
replaced http://mathematica.stackexchange.com/ with https://mathematica.stackexchange.com/
Mar 9, 2016 at 16:58 comment added Mr.Wizard @Leonid I thought maybe I do not understand unlikely's comment since I do not see the contradiction either.
Mar 9, 2016 at 16:57 comment added Leonid Shifrin @Mr.Wizard I think the quoted sentence actually does suggest exactly that "a conflict is searched between two declaration list of two nested scoping construct" - how else would one analyse the conflicts? So there is no contradiction.
Mar 9, 2016 at 16:51 comment added Mr.Wizard @Leonid Do you have a reply to the comment above? I am not entirely sure I understand it and since you wrote that part (thanks again) I think you're in a better position to reply.
Mar 9, 2016 at 8:11 comment added unlikely Yes, I "adapted" this sentence of the tutorial with the same "placeholder" symbols used in this answer because in this form appeared to me as a definitive synthesis but it also appeared (maybe) not completely in agreement with a sentence of this answer, ie. "If some inner scoping constructs are found where some variables conflict with vars, then Sc renames them." This last doesn't suggest that a conflict is searched between two declaration list of two nested scoping construct?
Mar 8, 2016 at 15:50 comment added Mr.Wizard @unlikely You seem to be quoting reference.wolfram.com/language/tutorial/… except that you use "ScInner" instead of Function. If one realizes that Function is not the only scoping construct and that renaming will take place elsewhere I think that pretty well summarizes it.
Mar 8, 2016 at 1:18 comment added unlikely "In general, the Wolfram Language renames the formal parameters in an object like ScInner[vars,body] whenever body is modified in any way by the action of another Sc." Is this a good syntesis now or there are still specific cases to consider?
May 27, 2014 at 11:27 comment added Jacob Akkerboom Re: "Function does nothing" (in your answer). This is only correct for Functions that use Slots. Please consider Function[x, Function[var, x]][2].
Mar 10, 2013 at 23:38 comment added Leonid Shifrin @Jens So, thanks for the input, in particular it shows that some people read what I write, carefully enough :). I will make an edit and make my statements more precise, some time soon.
Mar 10, 2013 at 23:36 comment added Leonid Shifrin @Jens Yes, the first case I actually noticed, but was too lazy to correct my wording. Basically, my main point was that the decisions about renamings are made by Module. In the case Module[{z},Function[z,0]], it was smart enough to realize that simply keeping x in Function would be enough to avoid cinflicts. As to the second case, this seems to be a general problem with Module (and more generally, the emulation of lexical scoping in Mathematica): take Module[{z$, z}, 1], and you get the same. I wasn't aware of this particular issue, but I am not too surprised either.
Mar 10, 2013 at 23:29 comment added Jens The problem with z$ is that it should count as a different variable since that's the replacement you get when doing this: Module[{z, expr}, expr = 1; Function[z, expr]]. Note here that the replacement is made from z to z$ in Function, whereas expr is actually not replaced at all again (it's the same name inside and outside Function).
Mar 10, 2013 at 23:06 comment added Jens @LeonidShifrin Going back to the case of Function, I think the description of variable renaming doesn't always apply. Take for example Module[{z},Function[z,0]]. Nothing is renamed at all. But then add Module[{z$,z},Function[z,0]] and you get an error.
Mar 7, 2013 at 5:05 comment added Rojo You've been Leonified!
Mar 7, 2013 at 2:37 history edited Leonid Shifrin CC BY-SA 3.0
Added a more interesting example
Mar 7, 2013 at 0:43 history edited Mr.Wizard CC BY-SA 3.0
edited body
Mar 7, 2013 at 0:04 vote accept einbandi
Mar 6, 2013 at 23:59 comment added acl @Leonid perfect
Mar 6, 2013 at 23:59 comment added Leonid Shifrin @acl See if you like the new title I just made for it.
Mar 6, 2013 at 23:57 comment added acl @Mr.Wizard I have been thinking about this for the past few minutes but don't see any lightweight modification that does the job. If you do, please change it (also @Leonid)
Mar 6, 2013 at 23:53 comment added Mr.Wizard @acl you could edit the question, or at least the title, to make some recognizable reference to the automatic renaming in nested scoping constructs.
Mar 6, 2013 at 23:51 comment added acl @Leonid, MrW nice answer; I don't think here's the best place to post it for visibility though. It is likely to be missed by people interested in this broad discussion. But I am not sure how to fix that (except by us linking to it in the future).
Mar 6, 2013 at 23:40 comment added ecoxlinux @Leonid Thanks.
Mar 6, 2013 at 23:19 comment added Leonid Shifrin @Mr.Wizard No problem. This is an important topic, so sooner or later we had to cover it somewhere.
Mar 6, 2013 at 23:18 comment added Leonid Shifrin @ecoxlinux These renamings are excessive, it seems - and it is also mentioned in the docs. So, yes, it sees the conflict in the body but does renamings of function's variables.
Mar 6, 2013 at 22:52 comment added ecoxlinux I am still not clear about what constitutes a conflict of variables. For example why Module[{body}, Function[x, body] /. body -> 2 x] and Module[{ }, Function[x, body] /. body -> 2 x] give different answers? It seems that in the first one, Module renames x, as it detects body inside Function, and this doesn't occur in the second one.
Mar 6, 2013 at 22:33 comment added Mr.Wizard @Leonid I didn't mean that at all. Thanks for the comprehensive addition!
Mar 6, 2013 at 22:05 comment added Leonid Shifrin I hope it did not insult you that I changed your original post considerably. Please feel free to roll back if you don't like it.
Mar 6, 2013 at 22:04 comment added Mr.Wizard That's quite the contribution @Leonid. :^)
Mar 6, 2013 at 21:57 comment added Leonid Shifrin @Szabolcs I did not really study the internal implementation, so all I can say about this has a status of an educated guess. I tried to describe this mechanism above, in my edit - see if you find this a satisfactory answer to your question.
Mar 6, 2013 at 21:53 history edited Leonid Shifrin CC BY-SA 3.0
Added some discussion on general mechanism of renaming
Mar 6, 2013 at 21:23 comment added Szabolcs @Leonid So what Module does is actually scan for Function, With, etc. not replace anything inside those? There isn't anything more complicated involved?
Mar 6, 2013 at 21:08 comment added Mr.Wizard @LeonidShifrin Of course I don't mind. :-)
Mar 6, 2013 at 21:02 comment added Leonid Shifrin I think it is still not clear enough. Do you mind if I contribute to your answer?
Mar 6, 2013 at 20:59 history edited Mr.Wizard CC BY-SA 3.0
added 128 characters in body
Mar 6, 2013 at 20:56 comment added Mr.Wizard @Leonid That is the point I was trying to make but I guess I didn't say it very well. I'll try again.
Mar 6, 2013 at 20:50 comment added Leonid Shifrin +1. The real reason why the version with Function[x, z] /. z -> expr does not work is that the one we are trying to fool here is not Function, but Module. It is Module that performs the renaming inside Function, and it uses verbatim search for Function[something] in the code of Module. This is why things like Function @@ ... work. I think it is important to realize this.
Mar 6, 2013 at 20:48 history edited Mr.Wizard CC BY-SA 3.0
added 30 characters in body
Mar 6, 2013 at 20:42 history edited Mr.Wizard CC BY-SA 3.0
added 793 characters in body
Mar 6, 2013 at 20:37 history answered Mr.Wizard CC BY-SA 3.0