Embedding domain-specific languages into R enriches the language by providing flexible ways to construct data structures or process data. In this book, we have seen how to use techniques such as operator overloading, meta-programming, and non-standard evaluation to implement small domain-specific languages. Through examples, we have explored several language designs for various problems.

The flexibility of the R language—flexibility both in how we can override operators and functions and specialize generic functions and flexibility in how we evaluate expressions—makes domain-specific languages a natural approach to designing package interfaces. The packages in the widely popular tidyverse exploit this to a great degree. The ggplot2 package uses the plus operator to combine graphical commands in the “grammar of graphics.” The magrittr pipe operator, %>%, is used to create sequences of transformation verbs in packages such as dplyr and tidyr. The tidyverse packages also exploit non-standard evaluation to over-scope expressions with data frame columns. As is evident from the popularity of the tidyverse, the use of well-designed domain-specific languages can improve the productivity of a programmer considerably. This happens as a consequence of improved readability and increased flexibility over more traditional interfaces to analysis frameworks.

A key word here is well-designed. When we implement a domain-specific language, rather than rely on standard R syntax, we demand of the user that he or she can use the language more efficiently than they could use a more traditional interface. This will be the case only if the language is designed to be consistent in how you combine its components and how it interacts with the surrounding R code.

Designing a language requires some trial and error. With experience, you will reduce the number of errors, of course, but you will always benefit from experimenting with alternative ways of expressing the same ideas. It is via experiments you will learn how different components of a language combine to express ideas. A good approach to designing a new domain-specific language is to consider various use cases and write down how you would ideally want to express the computations you want to implement in your new language. You don’t have to implement any of the language constructs yet; you can just try to write down expressions in various ways.

Once you are satisfied with how you would ideally want the language to look, you can start to worry about how you would implement it. It might not be possible to implement the language to accept exactly the syntax you came up with in the design phase. Since you are embedding the language in R, expressions in the language must also be valid R code. This puts some restrictions on what you can do. But starting from the ideal design, you can modify your use cases until the examples are valid expressions both in your language and in R, and from there, you can exploit the techniques you have learned in this book to implement your language.

Good luck.