Suspecting bug in Parallel Framework

Question

I've reduced my actual problem to:

ParallelEvaluate[
  Module[{slot=1},
    Slot[slot]
  ]
]

gives error messages that I think shouldn't be there. It seems I can work around them with

ParallelEvaluate[
  Module[{slot=1},
    Slot@@{slot}
  ]
]

and

ParallelEvaluate[
  Module[{slot=1,s=Slot},
    s[slot]
  ]
]

but I still think this is a bug in the parallel framework. Am I missing something obvious? It seems the numeric check happens with the local Module placeholder values passed to the parallelism framework in a syntactic way, not in a semantic way. But that's wrong, I should be able to pass Slot[anything]

v8.0.4 and v9 alike, Windows and Linux.

Answer 1

This message is issued by Function itself. To see this, try

Function[Module[{slot = 1}, Slot[slot]]]

If Function has named formal parameters, the message goes away:

Function[x, Module[{slot = 1}, Slot[slot]]]

So to fix this first we need to find out where is the argument passed to ParallelEvaluate wrapped by Function. Fortunately the parallel tools are defined in a plain .m (not .mx) file so we can read the source code. The relevant part turns out to be in $InstallationDirectory/AddOns/Applications/Parallel/Parallel.m, in the definition of Send:

Send[kernels:{___kernel}, expr_] := Send[#, expr]& /@ kernels

The part causing the problem is Send[#, expr]&. Looks innocent enough, doesn't it? If we change this to Function[k, Send[k, expr]] then the message goes away.

Warning: I do not know if the form of Function with named formal parameters can cause any trouble (e.g. name collisions) in certain edge cases so be careful (or ask Leonid) ... Update: Here's an example of what may go wrong with named formal parameters.

Perhaps you can report this problem to WRI and let us know what they said.

---

Now that we know what the problem is caused by, we can manually construct simple problem cases. For example,

Generally, passing any Slot not wrapped in a Function without formal arguments will cause problems (messages and unexpected results). I would consider this a bug, so I think it's a good idea to report it.

Answer 2

I would not classify this as a bug. The behaviour of a Slot expression that is not directly contained within a Function expression is not defined by the documentation, and is unreliable in practice. Consider the following two functions:

f[x_] := x + 100
g[x_] := x + # &[100]

They appear to be essentially equivalent, but it just so happens that the implementation of the second function involves a pure function. However, they return different results when passed a "dangling" slot reference (i.e. a slot reference that is not directly contained within a pure function):

f[#]
(* 100 + #1 *)

g[#]
(* 200 *)

The second result might surprise us, especially if the documentation for g said "adds 100 to its argument". Consider what happens if we call g with the Module expression from the question:

g[Module[{slot = 1}, Slot[slot]]]
(* 200 *)

200 is perhaps not exactly what we expected, but at least it is consistent with g[#].

On the other hand, let's try it with a new function h which is the same as g but holds its argument:

SetAttributes[h, HoldAll]
h[x_] := x + # &[100]

h[Module[{slot = 1}, Slot[slot]]]
(*
Function::slot: Slot[slot] (in Module[{slot=1},Slot[slot]]+#1&) should contain a non-negative integer. >>
(Module[{slot=1},Slot[slot]]+#1&)[100]
*)

We get the same warning message as in the question. This occurs because this expression ultimately resolves to:

Module[{slot = 1}, Slot[slot]] &

... which is manifestly incorrect since arguments to Slot in a function body must be non-negative integers -- not symbols.

ParallelEvaluate happens to be implemented somewhat like h. It holds the argument, and its implementation happens to use a pure function.

The moral of this story is that the behaviour of a dangling slot reference is essentially undefined. Its behaviour depends upon the exact implementation of the functions to which it is passed. If we are unaware of those exact implementation details, then we should avoid the use of dangling slot references since we can never be sure if that slot expression might not accidentally find its way into an internal Function expression.

To work around this difficulty, we can use a temporary symbol in place of Slot and then substitute it out after the evaluations are complete:

Module[{t}
, ParallelEvaluate[Module[{slot = 1}, t[slot]]] /. t -> Slot
]

This behaviour is just another example of the kind of "gotchas" that occur due to Mathematica's simulation of functional programming constructs through pattern matching techniques.

Answer 3

This is easily fixed by:

  Send[kernels:{___kernel}, expr_] := Table[Send[k, expr], {k, kernels}]

instead of

Send[kernels:{___kernel}, expr_] := Send[#, expr]& /@ kernels

While changing Parallel.m is one possibility, we can also
change the DownValues programmatically:

Parallel`Developer`Send;
Unprotect[Parallel`Developer`Send];
Parallel`Developer`Send[kernels : {___Parallel`Kernels`kernel}, expr_] := 
  Table[Parallel`Developer`Send[k, expr], {k, kernels}];
Protect[Parallel`Developer`Send];

This first idea is of giving Send Attribute Listable is wrong, thank's Oleksandr. Might be nice if there would be a ListableFirst attribute. But there is not.