Ceci n'est pas une pipe

[nhejazi]

Given the style in which delayed is intended to be used, it seems that it could benefit from the inclusion of a pipe operator -- perhaps something like %>...%. The design of such a pipe operator could work in the following manner (adapting the example in the package README):

library(delayed)
library(future)
set.seed(14765)
plan(multicore, workers = 2)
const <- 7

# write a function that will be delayed later
mapfun <- function(x, y) {(x + y) / (x - y)}

# define a delayed object by piping in functions and expressions
chained_norm_pois <- mapfun %>...%
  list("rnorm(n = const)", "rpois(n = const, lambda = const)")
 
# compute it using the future plan (multicore with 2 cores)
chained_norm_pois$compute(nworkers = 2, verbose = TRUE)

Internally, this would work by having the %>...% operator detect that mapfun is a function (perhaps via class()) and wrap it in delayed_fun, then proceed to pass in in the arguments that follow the pipe. Arguments could be provided by passing each member of the list object above to something like delayed(eval(parse(text = list[[1]]))), ..., delayed(eval(parse(text = list[[n]]))) over n, the length of the list -- effectively wrapping expressions in delayed. Of course, expressions already wrapped in delayed could also be provided, in which case the pipe need not wrap them in delayed redundantly.

This is just an initial proposal -- very much open to (and likely in need of) modifications prior to any effort being spent on implementation.