remotecall does not allow do-blocks  11406 Closed oxinabox opened this Issue on May 22, 2015 · 3 comments Projects None yet Labels decision parallel Milestone No milestone Assignees No one assigned 4 participants  oxinabox  malmaud  andreasnoack  simonster Notifications    oxinabox oxinabox commented on May 22, 2015  remotecall does no allow do-blocks to be used to specify the method to be runremotely. Because it takes its arguments as remotecall id,func,args... .  this means it can't be used with do-blocks do-blocks can only be used if the function takes a function as its first arg.  map, filter, open, etc all do this and so can have do blocks. remotecall is the only method  that i can bring to mind , which takes a function, not as its first arg.  I know I would really like to do remote call with do-blocks as I have many functions that exist only to be passed to remote call.  I'm not sure what the fix is. The obvious one is:  remotecall func, id, args...  which has the downside of not the args are not clearly associated with the function. But on the other hand, with closures we don't need to have the function take its arguements as arguments:  So all func calls like remotecall id,func,x  become  remotecall id  do        func x   end  Which is a improvement if func is define for this purpose -- you wouldn't literally write func in the closure you would define func as the closure.  if using an existing method you still have remotecall func,id,x  which as stated is ugly.  We could have both, using multiple dispatch. Since functions and ints are obviously different types. But perhaps tht might be too confusing?  What do people think? Is it worth making do blocks work for remotecall? Perhaps the do-block syntax is what needs to be changed instead.  simonster simonster added decision parallel labels on May 23, 2015  malmaud malmaud commented on May 23, 2015  You can already pass a do-block to  spawnat. Is that not sufficient?  andreasnoack The Julia Language member andreasnoack commented on May 23, 2015  See also https:  groups.google.com forum  !searchin julia-users Should$20we$20move$20the$20fn$20argument$20of$20remotecall$20and$20remotecall_fetch$20to$20first$20position$3F julia-users xxXFOIml7rA bvhjT5Hx4kAJ  I think we should change the order to allow do-blocks and I was actually about to make the change. The solution I decided to try had the arguments to the function in a tuple, i.e. remotecall f,args::Tuple,id .  malmaud malmaud commented on Oct 14, 2015  This was changed at some point, and now the remotecall family of functions do take the function as the first argument.  malmaud malmaud closed this on Oct 14, 2015  oxinabox oxinabox referenced this issue on May 10 Open finalizer takes it's arguements backwards  function should be first arguement   16307