Multi-Paradigm Pipeline Implementation

Provides various styles of function chaining methods: Pipe operator, Pipe object, and pipeline function, each representing a distinct pipeline model yet sharing almost a common set of features: A value can be piped to the first unnamed argument of a function and to dot symbol in an enclosed expression. The syntax is designed to make the pipeline more readable and friendly to a wide range of operations.

Linux Build Status Windows Build status CRAN Version

pipeR provides various styles of function chaining methods:

  • Pipe operator
  • Pipe object
  • pipeline function

Each of them represents a distinct pipeline model but they share almost a common set of features. A value can be piped to the next expression

  • As the first unnamed argument of the function
  • As dot symbol (.) in the expression
  • As a named variable defined by a formula
  • For side-effect that carries over the input to the next
  • For assignment that saves an intermediate value

The syntax is designed to make the pipeline more readable and friendly to a wide variety of operations.

pipeR Tutorial is a highly recommended complete guide to pipeR.

This document is also translated into 日本語 (by @hoxo_m).


Install the latest development version from GitHub:


Install from CRAN:


Getting started

The following code is an example written in traditional approach:

It basically performs bootstrap on mpg values in built-in dataset mtcars and plots its density function estimated by Gaussian kernel.

plot(density(sample(mtcars$mpg, size = 10000, replace = TRUE), 
  kernel = "gaussian"), col = "red", main="density of mpg (bootstrap)")

The code is deeply nested and can be hard to read and maintain. In the following examples, the traditional code is rewritten by Pipe operator, Pipe() function and pipeline() function, respectively.

  • Operator-based pipeline
mtcars$mpg %>>%
  sample(size = 10000, replace = TRUE) %>>%
  density(kernel = "gaussian") %>>%
  plot(col = "red", main = "density of mpg (bootstrap)")
  • Object-based pipeline (Pipe())
  sample(size = 10000, replace = TRUE)$
  density(kernel = "gaussian")$
  plot(col = "red", main = "density of mpg (bootstrap)")
  • Argument-based pipeline
  sample(size = 10000, replace = TRUE),
  density(kernel = "gaussian"),
  plot(col = "red", main = "density of mpg (bootstrap)"))
  • Expression-based pipeline
  sample(size = 10000, replace = TRUE)
  density(kernel = "gaussian")
  plot(col = "red", main = "density of mpg (bootstrap)")  



Pipe operator %>>% basically pipes the left-hand side value forward to the right-hand side expression which is evaluated according to its syntax.

Pipe to first-argument of function

Many R functions are pipe-friendly: they take some data by the first argument and transform it in a certain way. This arrangement allows operations to be streamlined by pipes, that is, one data source can be put to the first argument of a function, get transformed, and put to the first argument of the next function. In this way, a chain of commands are connected, and it is called a pipeline.

On the right-hand side of %>>%, whenever a function name or call is supplied, the left-hand side value will always be put to the first unnamed argument to that function.

rnorm(100) %>>%
rnorm(100) %>>%

Sometimes the value on the left is needed at multiple places. One can use . to represent it anywhere in the function call.

rnorm(100) %>>%
  plot(col="red", main=length(.))

There are situations where one calls a function in a namespace with ::. In this case, the call must end up with ().

rnorm(100) %>>%
rnorm(100) %>>%
  graphics::plot(col = "red")

Pipe to . in an expression

Not all functions are pipe-friendly in every case: You may find some functions do not take your data produced by a pipeline as the first argument. In this case, you can enclose your expression by {} or () so that %>>% will use . to represent the value on the left.

mtcars %>>%
  { lm(mpg ~ cyl + wt, data = .) }
mtcars %>>%
  ( lm(mpg ~ cyl + wt, data = .) )

Pipe by formula as lambda expression

Sometimes, it may look confusing to use . to represent the value being piped. For example,

mtcars %>>%
  (lm(mpg ~ ., data = .))

Although it works perfectly, it may look ambiguous if . has several meanings in one line of code.

%>>% accepts lambda expression to direct its piping behavior. Lambda expression is characterized by a formula enclosed within (), for example, (x ~ f(x)). It contains a user-defined symbol to represent the value being piped and the expression to be evaluated.

mtcars %>>%
  (df ~ lm(mpg ~ ., data = df))
mtcars %>>%
  subset(select = c(mpg, wt, cyl)) %>>%
  (x ~ plot(mpg ~ ., data = x))

Pipe for side effect

In a pipeline, one may be interested not only in the final outcome but sometimes also in intermediate results. To print, plot or save the intermediate results, it must be a side-effect to avoid breaking the mainstream pipeline. For example, calling plot() to draw scatter plot returns NULL, and if one directly calls plot() in the middle of a pipeline, it would break the pipeline by changing the subsequent input to NULL.

One-sided formula that starts with ~ indicates that the right-hand side expression will only be evaluated for its side-effect, its value will be ignored, and the input value will be returned instead.

mtcars %>>%
  subset(mpg >= quantile(mpg, 0.05) & mpg <= quantile(mpg, 0.95)) %>>%
  (~ cat("rows:",nrow(.),"\n")) %>>%   # cat() returns NULL
mtcars %>>%
  subset(mpg >= quantile(mpg, 0.05) & mpg <= quantile(mpg, 0.95)) %>>%
  (~ plot(mpg ~ wt, data = .)) %>>%    # plot() returns NULL
  (lm(mpg ~ wt, data = .)) %>>%

With ~, side-effect operations can be easily distinguished from mainstream pipeline.

An easier way to print the intermediate value it to use (? expr) syntax like asking question.

mtcars %>>% 
  (? ncol(.)) %>>%

Pipe with assignment

In addition to printing and plotting, one may need to save an intermediate value to the environment by assigning the value to a variable (symbol).

If one needs to assign the value to a symbol, just insert a step like (~ symbol), then the input value of that step will be assigned to symbol in the current environment.

mtcars %>>%
  (lm(formula = mpg ~ wt + cyl, data = .)) %>>%
  (~ lm_mtcars) %>>%

If the input value is not directly to be saved but after some transformation, then one can use =, <-, or more natural -> to specify a lambda expression to tell what to be saved (thanks @yanlinlin82 for suggestion).

mtcars %>>%
  (~ summ = summary(.)) %>>%  # side-effect assignment
  (lm(formula = mpg ~ wt + cyl, data = .)) %>>%
  (~ lm_mtcars) %>>%
mtcars %>>%
  (~ summary(.) -> summ) %>>%
mtcars %>>%
  (~ summ <- summary(.)) %>>%

An easier way to saving intermediate value that is to be further piped is to use (symbol = expression) syntax:

mtcars %>>%
  (~ summ = summary(.)) %>>%  # side-effect assignment
  (lm_mtcars = lm(formula = mpg ~ wt + cyl, data = .)) %>>%  # continue piping

or (expression -> symbol) syntax:

mtcars %>>%
  (~ summary(.) -> summ) %>>%  # side-effect assignment
  (lm(formula = mpg ~ wt + cyl, data = .) -> lm_mtcars) %>>%  # continue piping

Extract element from an object

x %>>% (y) means extracting the element named y from object x where y must be a valid symbol name and x can be a vector, list, environment or anything else for which [[]] is defined, or S4 object.

mtcars %>>%
  (lm(mpg ~ wt + cyl, data = .)) %>>%
  (~ lm_mtcars) %>>%
  summary %>>%


mtcars %>>%
  filter(mpg <= mean(mpg)) %>>%  
  select(mpg, wt, cyl) %>>%
  (~ plot(.)) %>>%
  (model = lm(mpg ~ wt + cyl, data = .)) %>>%
  (summ = summary(.)) %>>%
mtcars %>>%
  ggvis(~mpg, ~wt) %>>%
1:100 %>>% %% 3) %>>%
  list.mapv(g ~ mean(g))


Pipe() creates a Pipe object that supports light-weight chaining without any external operator. Typically, start with Pipe() and end with $value or [] to extract the final value of the Pipe.

Pipe object provides an internal function .(...) that work exactly in the same way with x %>>% (...), and it has more features than %>>%.


  density(kernel = "cosine")$
  plot(col = "blue")
  .(~ summary(.) -> summ)$
  lm(formula = mpg ~ wt + cyl)$

Subsetting and extracting

pmtcars <- Pipe(mtcars)
  lm(formula = mpg ~ wt)$

Assigning values

plist <- Pipe(list(a=1,b=2))
plist$a <- 0
plist$b <- NULL

Side effect

  .(? ncol(.))$
  .(~ plot(mpg ~ ., data = .))$    # side effect: plot
  lm(formula = mpg ~ .)$
  .(~ lm_mtcars)$                  # side effect: assign


  • Working with dplyr:
  filter(mpg >= mean(mpg))$
  select(mpg, wt, cyl)$
  lm(formula = mpg ~ wt + cyl)$
  • Working with ggvis:
  ggvis(~ mpg, ~ wt)$
  • Working with rlist:
Pipe(1:100)$ %% 3)$
  list.mapv(g ~ mean(g))$


pipeline() provides argument-based and expression-based pipeline evaluation mechanisms. Its behavior depends on how its arguments are supplied. If only the first argument is supplied, it expects an expression enclosed in {} in which each line represents a pipeline step. If, instead, multiple arguments are supplied, it regards each argument as a pipeline step. For all pipeline steps, the expressions will be transformed to be connected by %>>% so that they behave exactly the same.

One notable difference is that in pipeline()'s argument or expression, the special symbols to perform specially defined pipeline tasks (e.g. side-effect) does not need to be enclosed within () because no operator priority issues arise as they do in using %>>%.

  lm(formula = mpg ~ cyl + wt)
  ~ lmodel
  ? .$r.squared

Thanks @hoxo_m for the idea presented in this post.


This package is under MIT License.


Version 0.6

  • New features
    • Add pipeline function to support expression-based pipeline evaluation. (#60)
    • Piping to string now cat the string in the console. (#61)
    • Question mark now supports binary operation ("message" ? expression) in which expression is evaluated while "message" is printed ahead of its value. (#62)
  • Improvements
    • <<- and ->> now correctly performs global assignment in enclosed expression in a pipeline. (#65)

Version 0.5

Remove deprecated operators (%:>% and %|>%), deprecated closure fun() in Pipe object, and deprecated -> to build lambda expression. Support assignment in () with <- and ->. Improve the implementation of functions. Fix bugs.

Version 0.4-3

Add syntax for assignment: Side effect with a symbol Update documentation. Fix bugs for Pipe object

Version 0.4-2

Deprecate fun() in Pipe object, use .() instead. Deprecate lambda expression like (x -> expr), use (x ~ expr) instead. Add side-effect piping Add question piping Add subsetting, extracting, assigning to Pipe object Resolve compatibility issues with data.table (#28) Resolve evaluation environment issues (#20, #34)

Version 0.4-1

Add element extraction syntax Improve Pipe function Refine vignettes and documentation

Version 0.4

MAJOR API BREAK: %>>% operator handles all pipeline mechanisms (see README) and other operators are deprecated. Add Pipe object that supports object-based pipeline operation.

Version 0.3-3

Resolve issue #16 so that call-using functions will not get the piped object.

Version 0.3-2

Add vignettes Minor improvements

Version 0.3-1

Minor implementation improvements

Version 0.3

Major operator change

To avoid naming conflict with magrittr package (issue #12), the first-argument pipe operator is changed to %>>% and free pipe operator with dot is changed to %:>%. Now the three operators are:

First-argument piping: %>>% Free piping: %:>% Lambda piping: %|>%

Now this package can perfectly coexist with magritter and dplyr but is not backward compatible with previous code if old operators are used, please notify the potential issues and upgrade to the new set of operators if possible.

Version 0.2-4

Refined to adapt to CRAN standards.

Version 0.2-3

Minor changes to function descriptions

Version 0.2-2

This is a major refine of code for better compatibility.

Resolved issue #9 and #5.

Now the code is highly compatible with functions that have ... as an argument.

Version 0.2-1

This version is not compatible with v0.2 due to the switch of lambda expression symbol from -> to ~.

The reason is that using ~ directly refers to formula object that is more well defined and usable in this case, which does not diminish any feature in v0.2 but allows lambda expressions to store in symbols.

Version 0.2

  1. Add lambda piping %|>%
mtcars %|>%
  (df -> lm(mpg ~ ., data=df))
  1. %>>% no longer allows naked function calling
rnorm(100,10,1) %>>% log %>>% diff

is no longer allowed. You should always use %>% to call by function name like

rnorm(100,10,1) %>% log %>% diff

Version 0.1

Initial release

Reference manual

It appears you don't have a PDF plugin for this browser. You can click here to download the reference manual.

install.packages("pipeR") by Kun Ren, 6 years ago,,

Report a bug at

Browse source code at

Authors: Kun Ren <[email protected]>

Documentation:   PDF Manual  

MIT + file LICENSE license

Suggests testthat

Imported by RDML, getLattes, milr, rAmCharts.

Depended on by analysisPipelines.

Suggested by backpipe, regexPipes, sunburstR.

See at CRAN