The Strange and Wondrous Life of Functions in Ř
R is a dynamic programming language with a plethora of features and packages. It is functional and object-oriented, vectorized, lazy and reflective. However, at the heart of darkness lies R’s function call. This applies not only to user-defined functions, but also to arithmetics, assignments, and control flow constructs – all of those are function calls.
To call a function, one first needs to look up the callee. Name lookup has a humorous interaction with lazy evaluation as the language pretends it has distinct environments for function definitions, but only differentiates between variables and functions on demand. Once a target function is identified, arguments are packed into promises which contain both source code for reflection and current environment for evaluation. Arguments can, optionally, be annotated with names. The process of matching passed arguments to expected parameters requires dealing with positional arguments as well as with, possibly reordered, nominal arguments. Nominal arguments support partial name matches, thus ‘f=42’ can match parameters ‘foo’ or ‘foobar’. An ellipsis can occur both in the argument list of a call and in the definition of the parameters with slightly different semantics. As a parameter, ‘…’ means a variable number of arguments, between zero and many. As an argument, ‘…’ is expanded to its individual components, which can be named, and those names are exactly as given at the origin of the ellipsis. If an argument is not provided, the corresponding parameter will be tagged as missing, yet as parameters can have default values, a missing parameter can evaluate to ‘42’. Of course, a missing parameter that has no value causes an error, but only if it is accessed in the callee. Finally, when the function is ready to be called an environment is created with the matched parameters. Additionally, a stack frame for this function is populated with data about the call such as the AST, the called closure, the caller environment, or the list of promises given at the callsite. Moreover, some entries of this frame are accessible through reflection.
In our work on Ř we need to deal with all of these. We strip away all of the fat that surrounds function calls and only retain the features that are likely to be needed. As this talk will illustrate this is easier said than done.
Tue 23 MarDisplayed time zone: Belfast change
15:00 - 16:30
Performance and BenchmarkingMoreVMs at Virtual Space A
Chair(s): Sophie Kaleba University of Kent
|The Strange and Wondrous Life of Functions in Ř|
Jan Ječmen FIT CTU Prague, Olivier Flückiger Northeastern University, Sebastián Krynski Czech Technical University, National University of Quilmes, Jan Vitek Northeastern University / Czech Technical UniversityMedia Attached
|Successes and Challenges in Bringing Performance to Java with Inline Types|
Sharon Wang IBMMedia Attached File Attached
|Towards a Synthetic Benchmark to Assess VM Startup, Warmup, and Cold-Code Performance|
Stefan Marr University of KentMedia Attached