A principled approach to REPL interpreters

Abstract

Read-eval-print-loops (REPLs) allow programmers to test out snippets of code, explore APIs, or even incrementally construct code, and get immediate feedback on their actions. However, even though many languages provide a REPL, the relation between the language as is and what is accepted at the REPL prompt is not always well-defined. Furthermore, implementing a REPL for new languages, such as DSLs, may incur significant language engineering cost.In this paper we survey the domain of REPLs and investigate the (formal) principles underlying REPLs. We identify and define the class of sequential languages, which admit a sound REPL implementation based on a definitional interpreter, and present design guidelines for extending existing language implementations to support REPL-style interfaces (including computational notebooks). The obtained REPLs can then be generically turned into an exploring interpreter, to allow exploration of the user's interaction.The approach is illustrated using three case studies, based on MiniJava, QL (a DSL for questionnaires), and eFLINT (a DSL for normative rules). We expect sequential languages, and the consequent design principles, to be stepping stones towards a better understanding of the essence of REPLs.

eFLINT: a domain-specific language for executable norm specifications

“…normative actors. Benefiting from the principled approach to REPLs presented in [33], the back-end of the REPL has been reused to form the basis of a TCP server. The server is loaded with a specification and waits for incoming declarations, statements and queries on a given port.…”

“…In the design of eflint, focus has been on the possibility to simultaneously use specifications in isolation -typically with a finite domain -as well as in in running systemstypically with an open-ended domain. To this end, the language has a reactive, REPL-oriented design, based on [33], supporting manual exploration and enabling external systems to trigger actions and events. This motivation guided other design choices as well, such as the semantics of Foreach and the ability to redefine types to form specialized domains.…”

Codepod: A Namespace-Aware, Hierarchical Jupyter for Interactive Development at Scale

“…The problem with this approach is that it is non-interactive, and the program always needs to restart from the beginning. An interactive development method is to launch a Read-Eval-Print-Loop (REPL) [7,14], type, load, and evaluate code expressions in the REPL. Although REPL is interactive, the code being evaluated is not editable, and users have to type code into the REPL.…”

Making the Invisible Visible in Computational Notebooks

“…enabling the programmer to update their mental model of the program state and making predictions about the effects of the next code fragment [8]. In our notebooks based on exploring interpreters, the effects of code executions manifest as changes to the 'current configuration'.…”

“…This paper presents the benefits of using a so-called 'exploring interpreter' as the back-end for notebooks and explains how to develop interactive widgets interacting with an exploring interpreter. An exploring interpreter is a bookkeeping device on top of an existing interpreter that keeps track of program state by maintaining an execution graph of reached states and allows reverting to previous states to explore alternative paths [8], [9]. This paper presents initial results of a study into the extent to which exploring interpreters are sufficient to support exploratory styles of programming in programming environments for end-users.…”