Piping operators

The most widely known example is the piping operator: %>%. I assume that you are familiar with it. If not, you better get to know the dplyr package. The pipe comes from magrittr package, but dplyr shows its natural strength and the most significant advantage of using custom operators: custom infixes make code more readable. When we apply operations one by one, it makes more sense to write those operations in order of application, not inverse order, as we do without infix operators. The operator’s shape is also essential, as it suggests the direction of the data flow. For me, it is more natural to read and understand

x %>% 
  fun_1 %>% 
  fun_2 %>% 
  fun_3

rather than

fun_3(fun_2(fun_1(x)))

It became so popular that R 4.1.0 included its pipe, |>. However, I will not dwell more on that because others have already said a lot about pipes. I only want to mention, what is often forgotten by newcomers, that magrittr offer more than one type of pipe. Go check them out if you don’t know them!

NULL-default operator

Another tremendous and straightforward function is %||%. It is exported by the rlang package (it’s the turtleblog after all”, so rlang mention is obligatory), but other packages borrow this idea to avoid dependency. The code is straightforward and clearly explains what the function is intended to do.

`%||%` <- function(lhs, rhs) if (is.null(lhs)) rhs else lhs

34 %||% 8
## [1] 34
NULL %||% 10
## [1] 10

This one comes in handy when you have optional NULLs returned by a function or possibly NULL parameters of the function or named function arguments. In the code, it looks way more straightforward than the expansion of the function definition itself. I usually do not export such a helper function to the end user. But it is worth repeating that readability of your code for yourself should be as important as readability for others. If such infixes help you, then you should use them.

NULL-propagating operator

Let’s stay with NULL-related functions for a little longer. Now it is time for my creation. When I build packages or shiny apps, it happens quite often that I need to apply some function to some object, but if it is NULL, I need to return NULL. For those situations, I created the %?>% operator:

`%?>%` <- function(lhs, rhs) if (is.null(lhs)) NULL else rhs(lhs)

7 %?>% exp
## [1] 1096.633
NULL %?>% exp
## NULL

This one is some modification of a standard pipe but serves a specific purpose. It simplified my code significantly, and I love it for its conciseness.

Motif inclusion operator

Now, an example from one of our packages, tidysq. It is a package for the tidy processing of biological sequences. Here we implemented the %has% operator that checks for the presence of specific motifs in sequences.

library(tidysq)

sq(c("AAAA", "AGCA", "CGCG", "TTCG")) %has% "GC"
## [1] FALSE  TRUE  TRUE FALSE

Laura and I found it very in line with the tidyverse philosophy of code being readable and understandable by others. It can be especially seen in dplyr processing pipes.

library(dplyr)

tibble(
  id = 1:4,
  sequence = c("LVGWEK", "KLLCVN", "ER", "LLLY")
 ) %>%
  mutate(sequence = sq(sequence)) %>%
  filter(sequence %has% "LL")
## # A tibble: 2 × 2
##      id sequence  
##   <int> <ami_bsc> 
## 1     2 KLLCVN <6>
## 2     4 LLLY   <4>

Ternary if operator

Finally, one fancy trick! Have you programmed in any language that contains ternary if operator? E.g., in C++, it looks like this:

(1 > 0) ? 'A' : 'B'

// would return 'A'

If the expression on LHS of ? is TRUE, a value between ? and : is returned. Otherwise, the value after : is returned. Why use it over regular if-else? It is an expression, while standard if in C and C++ is not an expression. Thus, the user can assign the result of this expression to any variable.

Do you miss it in R? Probably not. In R, if is an expression, so we have:

if (1 > 0) "A" else "B"
## [1] "A"

But what if we really wanted to have something in R more like in C++? Here you go!

`%?%` <- function(lhs, rhs) {
  values <- rlang::enexpr(rhs)
  if (values[[1]] != as.symbol(":"))
    stop("RHS for `%?%` operator has to be in the form of '*:*' where '*' are any expressions")
  if (lhs) rlang::eval_bare(values[[2]]) else rlang::eval_bare(values[[3]])
}

(1 > 0) %?% "A" : "B"
## [1] "A"

I did it only because I can.

As you can see, I also abused the : operator; not overrode: abused. Inside the function, the RHS argument is in the form expr:expr. Normally that would result in range. But here I used the non-standard evaluation, using rlang::enexpr() and ralng::eval_bare() to actually stop R from doing what it usually does. I will probably go into detail about it some other time; right now, enjoy the fanciness.

Remark about precedence

One thing to remember: operators have specific precedence. Those that have been programming for longer know that well from an autopsy. Those that have just started programming will get to know that. Custom infix functions obey those rules as well, and you sometimes may get surprised. You can check that the operators I provided may sometimes be misleading and require parentheses to work correctly. It is worth checking out R operator precedence manual page when in doubt.