You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
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)
becomeWhich 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.
The text was updated successfully, but these errors were encountered: