From rhe|p @end|ng |rom eoo@@dd@@n|  Wed Dec  9 15:55:52 2020
From: rhe|p @end|ng |rom eoo@@dd@@n| (Jan van der Laan)
Date: Wed, 9 Dec 2020 15:55:52 +0100
Subject: [Rd] New pipe operator
In-Reply-To: <CAP01uR=vTJ_uy+RURVZnA8vbnnPRTOUkn6a2AEkg4HG2Lu3kaQ@mail.gmail.com>
References: <e55c2093-0bb5-5f9b-5521-0ca8bdf35953@gmail.com>
 <CALyqOb8c1hHOSaMV+fqXTwpeOsP--KJ_t-oeqMYYafVXeNpqZg@mail.gmail.com>
 <7586e034-e287-0970-6480-f82d747b5445@gmail.com>
 <CADfFDC7bT58_+52uvmpHuMMQRNbbmqV3_7t_fc4sgJ_Esw=xag@mail.gmail.com>
 <CAJmOi+PO_8XDC23=rT=pQ76ENL=gx2V-41ax2fHSVs87xURcEA@mail.gmail.com>
 <CAP01uRkkd3jOjvaS9JgKYCD1KA83HfzCd+MQSv_2aYJPgcOmSQ@mail.gmail.com>
 <CAP01uRkPcbCBRGwAzKM=W19Ohh-zDGwZH8gM7=A-sK2rRaQxaQ@mail.gmail.com>
 <CAD4oTHFBY4rBhiRsJUkA6jwD2YWaxPMz2OZDOqSvHfv6A7DZPg@mail.gmail.com>
 <CAP01uRmTYna1nM+ugELHrCqLjfWuWwHSfE4cvqoaq2537sHpAw@mail.gmail.com>
 <CAD4oTHHFWkiirncPRWngY+_k9HcB=8zo7VdXAONXQoXdNhKzDA@mail.gmail.com>
 <7e28d84a-f6d0-1e18-c131-163650e7cd75@gmail.com>
 <CAP01uR=vTJ_uy+RURVZnA8vbnnPRTOUkn6a2AEkg4HG2Lu3kaQ@mail.gmail.com>
Message-ID: <d5010e6f-f997-48f5-744c-2c9bc760d523@eoos.dds.nl>



On 08-12-2020 12:46, Gabor Grothendieck wrote:
> Duncan Murdoch:
>> I agree it's all about call expressions, but they aren't all being
>> treated equally:
>>
>> x |> f(...)
>>
>> expands to f(x, ...), while
>>
>> x |> `function`(...)
>>
>> expands to `function`(...)(x).  This is an exception to the rule for
> 
> Yes, this is the problem.  It is trying to handle two different sorts of right
> hand sides, calls and functions, using only syntax level operations and
> it really needs to either make use of deeper information or have some
> method that is available at the syntax level for identifying whether the
> right hand side is a call or function.  In the latter case having two
> operators would be one way to do it.
> 
>    f <- \(x) x + 1
>    x |> f()  # call
>    x |:> f  # function
>    x |:> \(x) x + 1  # function
> 
> In the other case where deeper information is used there would only be one
> operator and it would handle all cases but would use more than just syntax
> level knowledge.
> 
> R solved these sorts of problems long ago using S3 and other object oriented
> systems which dispatch different methods based on what the right hand side is.
> The attempt to avoid using the existing or equivalent mechanisms seems to have
> led to this problem.
> 



I think only allowing functions on the right hand side (e.g. only the |> 
operator and not the |:>) would be enough to handle most cases and seems 
easier to reason about. The limitations of that can easily be worked 
around using existing functionality in the language.

The problem with only allowing

x |> mean

and not

x |> mean()

is with additional arguments. However, this can be solved with a 
currying function, for example:

x |> curry(mean, na.rm = TRUE)

The cost is a few additional characters.

In the same way it is possible to write a function that accepts an 
expression and returns a function containing that expression. This can 
be used to have expressions on the right-hand side and reduces the need 
for anonymous functions.

x |> fexpr(. + 10)
dta |> fexpr(lm(y ~ x, data = .))

You could call this function .:

x |> .(. + 10)
dta |> .(lm(y ~ x, data = .))


Dummy example code (thanks to  a colleague of mine)


fexpr <- function(expr){
   expr <- substitute(expr)
   f <- function(.) {}
   body(f) <- expr
   f
}
. <- fexpr

curry <- function(fun,...){
   L <- list(...)
   function(...){
     do.call(fun, c(list(...),L))
   }
}

`%|>%` <- function(e1, e2) {
   e2(e1)
}


1:10 %>% mean
c(1,3,NA) %|>% curry(mean, na.rm = TRUE)
c(1,3,NA) %|>% .( mean(., na.rm = TRUE) ) %>% identity
c(1,3,NA) %|>% .( . + 4)
c(1,3,NA) %|>% fexpr( . + 4)
c(1,3,NA) %|>% function(x) mean(x, na.rm = TRUE) %>% fexpr(. + 1)

--
Jan



[Rd] New pipe operator
Jan van der Laan