MathGroup Archive 2009

[Date Index] [Thread Index] [Author Index]

Search the Archive

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?
>
>


  • Prev by Date: Re: Determine if a parameter is a function
  • Next by Date: Re: False divergence of the NDSolve solution: how to avoid
  • Previous by thread: Re: Bug, quirk or expected behavior of Slot[]?
  • Next by thread: Re: Bug, quirk or expected behavior of Slot[]?