Re: Bug, quirk or expected behavior of Slot[]?

*To*: mathgroup at smc.vnet.net*Subject*: [mg101828] Re: [mg101759] Bug, quirk or expected behavior of Slot[]?*From*: Leonid Shifrin <lshifr at gmail.com>*Date*: Sat, 18 Jul 2009 04:52:07 -0400 (EDT)*References*: <200907161219.IAA02496@smc.vnet.net>

Hi Salvatore, I think Function with Slots (#-notation) is still a scoping construct rather than a macro, which can be illustrated be the following: In[1]:= Function[Function[#1+#2][#2]+#1][1,2] During evaluation of In[1]:= Function::slotn: Slot number 2 in #1+#2& cannot be filled from (#1+#2&)[2]. >> Out[1]= 3+#2 Were it a macro, then the #1 inside inner Function would be filled with the #1 from the outer one (the passed parameter 1 in this case). Slots are just another compact way to denote variables in pure functions. They will never be renamed, as named variables in Function[vars,body], but in a sense they restrict you more in what you can do. For instance, I don's see an easy way to get this kind of nested function Function[{t, x}, Function[y, t + y][x]] expressed in pure # - notation. Since no argument renaming is ever needed, functions expressed # - notation are usually faster than those with named arguments, although this effect will only be observable if the body of your function does very little. A few more differences: you can use SlotSequence (##) to define pure functions on arbitrary (variable) number of arguments - I don't knowany straightforward way of doing this for functions with named arguments. You also can write recursive pure functions like this: fact = If[#==0,1,#*#0[#-1]]& (where #0 stands for a function itself) for which I also don't know an analog for named arguments version. The hack found by Bastian: Function[t, Module[{y = 0}, t === y]][y$] seems to me rather an anomaly (this was based on the exact knowledge that Module is going to rename y to $y before producing the new symbol based on y$ and performing the binding - that is, on rather specific implementation details) than a general case. So, conclusions: IMO, Function[body] with slots (#) is a scoping construct in terms of variable binding, but does not rename variables, and is more restricted in terms of nesting than the version with named arguments (you can nest, of course, but have to be careful since otherwise it won't do what you intend, since variable (slot) collisions are not resolved by the system). I discussed similar topics in my book: http://www.mathprogramming-intro.org/book/node50.html Hope this helps. Regards, Leonid On Thu, Jul 16, 2009 at 5:19 AM, Salvatore Mangano < smangano at into-technology.com> wrote: > Someone on the "Linked In" Mathematica User group pointed this out to me: > > > In[26]:= Clear[y] > Function[Module[{y=0},#===y]][y] > Function[Module[{y=0},#1===y]][y] > Function[t,Module[{y=0},t===y]][y] > > Out[27]= True > Out[28]= True > Out[29]= False > > It leads me to believe # is more like a placeholder for macro-like > substitution than a formal parameter like t. > > Thoughts? > >

**References**:**Bug, quirk or expected behavior of Slot[]?***From:*Salvatore Mangano <smangano@into-technology.com>

**Re: Determine if a parameter is a function**

**Re: False divergence of the NDSolve solution: how to avoid**

**Re: Bug, quirk or expected behavior of Slot[]?**

**Re: Bug, quirk or expected behavior of Slot[]?**