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.
Talk slides (ICOOOLPS21.pdf) | 2.57MiB |
Tue 13 JulDisplayed time zone: Brussels, Copenhagen, Madrid, Paris change
13:00 - 17:30 | |||
13:00 5mOther | Welcome ICOOOLPS | ||
13:05 25mTalk | The Two Cultures of Language ImplementationInvited Talk ICOOOLPS Stephen Kell King's College London | ||
13:30 20mPaper | Naïve Transient Cast Insertion Isn’t (That) BadPaper ICOOOLPS P: Erin Greenwood-Thessman Victoria University of Wellington, Isaac Oscar Gariano Victoria University of Wellington, Richard Roberts Victoria University of Wellington, Stefan Marr University of Kent, Michael Homer Victoria University of Wellington, James Noble Victoria University of Wellington DOI Pre-print | ||
13:50 20mTalk | Threaded Code Generation with a Meta-tracing JIT CompilerPosition Paper ICOOOLPS P: Yusuke Izawa Tokyo Institute of Technology, Hidehiko Masuhara Tokyo Institute of Technology, CF Bolz-Tereick , Youyou Cong Tokyo Institute of Technology Pre-print | ||
14:10 10mSocial Event | Break ICOOOLPS | ||
14:20 20mTalk | Avoiding Monomorphisation Bottlenecks with Phase-based Splitting ICOOOLPS P: Sophie Kaleba University of Kent, Stefan Marr University of Kent, Richard Jones University of Kent Pre-print | ||
14:40 20mTalk | Native Implementation of Mutable Value SemanticsPosition Paper ICOOOLPS P: Dimi Racordon University of Geneva, Switzerland, Denys Shabalin EPFL, Switzerland, Dave Abrahams Google, Dan Zheng Purdue University, Google Brain, Brennan Saeta Google Pre-print | ||
15:00 20mTalk | An Eclipse OMR-based Garbage Collector for Python ICOOOLPS P: Joannah Nanjekye University of New Brunswick, David Bremner University of New Brunswick, Aleksandar Micic IBM, Canada | ||
15:20 20mSocial Event | Break ICOOOLPS | ||
15:40 20mTalk | Userfault Objects: Transparent Programmable MemoryPosition Paper ICOOOLPS Pre-print | ||
16:00 20mTalk | The Strange and Wondrous Life of Functions in Ř ICOOOLPS Jan Ječmen , Olivier Flückiger Northeastern University, Sebastián Krynski Czech Technical University in Prague, P: Jan Vitek Northeastern University / Czech Technical University File Attached | ||
16:20 20mTalk | Non-Intrusive Migration from Lazy to Eager Evaluation ICOOOLPS P: Aviral Goel Northeastern University, Jan Vitek Northeastern University / Czech Technical University | ||
16:40 10mSocial Event | Break ICOOOLPS | ||
16:50 20mTalk | A Framework and DSL for Distributed, Energy-constrained, and Time-sensitive Applications ICOOOLPS P: Kyle Liang Carnegie Mellon University, Reese Grimsley CMU, Eve Hu CMU, Edward Andert Arizona State University, Mohammad Khayatian Arizona State University, Aviral Shrivastava Arizona State University, Carlee Joe-Wong CMU, Jonathan Aldrich Carnegie Mellon University, Bob Iannucci CMU | ||
17:10 20mTalk | Fuel: A Compiler Framework for Safe Memory ManagementPosition Paper ICOOOLPS Dimi Racordon University of Geneva, Switzerland, P: Aurélien Coet University of Geneva, Switzerland, Didier Buchs University of Geneva, Switzerland Pre-print |