useR!2017

Keywords: tidyeval, tidyverse, dplyr, quasiquotation, NSE
Webpages: https://CRAN.R-project.org/package=dplyr, https://github.com/hadley/rlang
Evaluating code in the context of a dataset is one of R’s most useful feature. This idiom is used in base R functions like subset() and transform() and has been developed in tidyverse packages like dplyr and ggplot2 to design elegant grammars. The downside is that such interfaces are notoriously difficult to program with. It is not as easy as it should be to program with dplyr inside functions in order to reduce duplicated code involving dplyr pipelines. To solve these issues, RStudio has developed tidyeval, a set of new language features that make it straightforward to program with these grammars. We present tidyeval in this talk with a focus on solving concrete problems with popular tidyverse packages like dplyr.

Keywords: programming, functional-programming
Webpages: https://CRAN.R-project.org/package=modules, https://github.com/wahani/modules
In this talk I present the concept of modules inside the R language. The key idea of the modules package is to provide a unit of source code which is self contained, i.e. has it’s own scope. The main and most reliable infrastructure for such organisational units of source code is a package. Compared to a package modules can be considered ad-hoc, but still self contained. That means they come with a mechanism to import dependencies and also to export member functions. However, modules do not act as replacements for packages. Instead they are a unit of abstraction in between functions and packages.
There are two use cases in which modules can be beneficial. First when we write scripts and want to use sourced functions or, in general, need more control of the enclosing environment of a function. Here we may be interested to be able to state the dependencies of a function close to its definition; and also without the typical side effects to the global environment of the current R session. Second, as an organisational unit inside packages. Here modules can act as similar entities as objects in object-oriented-programming. However, other languages with similar concepts are mostly functional and the design borrows from languages like julia, Erlang and F#. As a result modules are not designed to contain data. Furthermore there is no formal mechanism for inheritance. Instead several possibilities for module composition are implemented.

Keywords: Compiler, Byte-Code, Interpreter, Performance
Webpages: http://www.stat.uiowa.edu/~luke/R/compiler/compiler.pdf
Since version 2.13, R includes a byte-code compiler and interpreter which complement the older abstract-syntax-tree (AST) interpreter. The AST interpreter directly executes R code represented as a tree of objects produced by the parser. The byte-code compiler compiles the AST into a sequence of byte-code instructions, which is then interpreted using a byte-code interpreter. The byte-code compiler and interpreter implement a number of performance optimizations which speed up scalar code and particularly loops operating on scalar variables. Performance of highly vectorized code is likely to be unaffected by the byte-code compiler/interpreter as in fact such code spends most of the time executing outside the R interpreters. The compiler can compile packages at installation time and individual R functions on request. It can also transparently compile loops and functions as they execute (just-in-time).
The talk will show examples of code that runs particularly fast with the compiler, code that is unaffected by it, and code that runs particularly slow. The slowdowns are almost always due to time spent in compilation; once compiled and loaded, the code should not run slower than in the unoptimized AST interpreter. When triggered just-in-time, the compiler includes heuristics that try to prevent compilation in case it is not likely to pay off, but sometimes they are wrong. The talk will show on concrete examples how these overheads can be avoided. The talk will be technical and will be aimed at package authors and R users who write performance critical R code.

Keywords: HaskellR, Haskell, Interoperability
Surely there’s no need to explain to useR! attendees what’s so great about R! Haskell, on the other hand, is a great language too - statically typed, purely functional, lazy, fast, and with that, you know, cool and mathy touch … ;-)
Statistics, data science, and machine learning, however, are not that easy to do from Haskell, as it does not have all the specialized and comfortable-to-use libraries R has.
Fortunately, the guys at tweag.io developed HaskellR, providing Haskell with full R interoperability. With ihaskell-inline-R, R can even be used in IHaskell notebooks. In this session, we’ll show how to get started with HaskellR, and how you can get the best of both worlds.