Towards a Language Parametric World: The Language Parametric Read-Eval-Print Loop Author: Jeroen Lappenschaar Supervisor: Paul Klint Amsterdam, June 16, 2014 Abstract The Read-Eval-Print Loop (REPL) has proven itself to be a useful tool for software developers. New languages, especially DSLs, often don't have these dedicated tools. This thesis researches whether a REPL can be parametrized for any language, and if so, how it should be instantiated. This is done in three parts: (1) An analysis is made of the features in a REPL and its language dependencies, (2) an overview of 13 popular REPLs and their features is given, and finally (3) the results of a proof-of-concept implementation are discussed. The thesis contributes with a domain analysis about the REPL and concludes with pointers on the parametrization of languages and their features. Contents 1 Introduction 3 1.1 Research . .4 1.1.1 Language-parametric REPL . .4 1.1.2 Exploratory research . .5 1.2 Set-up . .5 2 Background 6 2.1 An introduction . .6 2.2 The definition . .7 2.3 Implementation . .8 2.4 Related topics . .9 2.4.1 Language workbenches . .9 2.4.2 Reusable REPLs . .9 2.5 Summary . 10 3 A REPL Comparison 11 3.1 Hands-on . 11 3.2 Selection . 12 3.2.1 REPL Selection . 12 3.2.2 Feature Selection . 12 3.3 REPL feature overview . 13 3.4 Results . 17 4 Parametrization 19 4.1 REPL Parametrization . 19 4.2 Feature parametrization . 19 4.2.1 Available information . 20 4.2.2 Statement Actions . 20 4.2.3 Statement Features . 23 4.2.4 Information Features . 25 4.2.5 Session Actions . 28 4.2.6 Code-file Actions . 29 4.3 Dependency Conclusion . 31 4.4 Feature Relations Conclusion . 33 5 A LP-REPL Implementation 34 5.1 Environment set-up . 34 5.1.1 Java . 34 5.1.2 Rascal . 34 1 5.1.3 Evaluator integration . 35 5.2 The Implementation . 35 5.2.1 Metrics . 37 5.2.2 Architecture . 37 5.2.3 Basic REPL . 38 5.2.4 Features . 39 5.3 Resulting interfaces . 40 5.3.1 Command interface . 40 5.3.2 Java Evaluators . 42 5.3.3 Rascal DSL Evaluator . 42 5.3.4 Interface analysis . 43 5.4 Summary . 43 6 Conclusion 44 Bibliography 48 A Choice of REPLs 49 B REPL hands-on experience 50 C Java Interface 54 2 Chapter 1 Introduction Software development tools haven proven their worth from the day they were first created. They make problems more insightful (e.g., debuggers, profilers), they save developers from mind robbing tasks (e.g., automatic builders, unit testing), help or save time in any other matter (e.g., bug databases, code generation, code formatting). There are many more tools to name, and as many reasons for using them. Some of these tools can be used for any programming language (e.g., code revision, bug databases) but most of them are dedicated to a single language. With the development of a language the development of these tools often quickly follows. They provide an easier introduction to new developers and pave way for the adoption of the language. The development of these tools takes time however. Specifically for the development of Domain Specific Languages (DSLs) this is not desirable. These tools are meant to be quickly developed and quickly put to use. It is not desirable to keep creating dedicated development tools for every developed language. Language workbenches have been developed to solve exactly this problem. They offer the developer an IDE that directly integrates with the language that is being developed. Most of these workbenches already offer integrated features like syntax highlighting, code folding, error marking and refactoring [7]. A tool that has not yet been added to any of these language workbenches in a parametrized fashion is the Read-Eval-Print Loop (REPL). A REPL is often described as an interactive console where one can run code line by line and instantaneously see its result. It is the console that most people will know from languages like Haskell, Scala, Python or any of the LISP dialects. Figure 1.1 shows an example of a typical REPL. Figure 1.1: An example of a typical REPL. In this case we see a Linux terminal where the default Ruby REPL (irb) is running. The already run code shows how a user can test statements, create variables and call library functions. 3 The main advantage of a REPL is the direct interaction that it offers with code. To test just a specific function, a developer often creates a special main function, creates help functions and/or comments out any part of the code. The REPL replaces this necessity by facilitating access to any code in development and interaction with that code. This helps developers in the following cases: • Testing and debugging: One can quickly test any function with any parameter1. • Learning the language: The REPL instantaneously displays the result of the entered code, which is ideal for users who want to explore or experiment with the language. In short: \REPLs facilitate exploratory programming and debugging because the read-eval-print loop is usually much faster than the classic edit-compile-run-debug cycle." [34]. 1.1 Research So far we have seen the need for multi-language tools and a language specific tool, the REPL. A combination of this, a REPL that can be parametrized for different languages, would bring all the benefits of the REPL to any language. This would especially benefit new developed languages who need to be tested and learned by its users. To examine this, the research topic of this thesis will be: How can we design a language-parametric REPL, and how can it be instantiated for different languages? The purpose of this research is twofold: 1. To give an example implementation of a language parametrized REPL. 2. Let this be an explorative research for language parametrization of development tools in the scope of DSLs. Both purposes will be discussed next. 1.1.1 Language-parametric REPL Creating a language-parametric REPL will make all advantages of a REPL easily available for all languages. Next to the already mentioned advantages of a REPL this has an added benefit in some cases: • First, it supports language development. The language developer often has to test simple statements to see if everything (syntax, grammar, parser, interpreter/compiler) is working as hoped. As we have seen, the REPL is an ideal tool for this job. • Secondly, a new language needs to be learned by the users. In the case of DSLs there are higher chances that these people have no previous experience with programming. The experimental and explorative benefits of the REPL will help them here. • Lastly, the REPL offers a user-friendly interface for the new language that can instantly be accessed. 1Some REPLs even have the option to control the debugger from the console. 4 1.1.2 Exploratory research The second purpose of this thesis is to see how tools in general, can be made language- parametric. Information gathered here could be used to improve on existing language work- benches. The REPL, with all its features, affects many aspects of a language, and the analysis about this can give insight into: • What parts of a tool or feature are language specific. • How can the necessary information from the languages be shared. 1.2 Set-up To answer the research question, a domain analysis of the REPL is performed. This is done by performing background research in the literature (Chapter 2) and a thorough analysis of the most popular or outstanding REPLs (Chapter 3). It turns out that a big part of a REPL is formed by its many possible features. We defined these features and analysed how they could be parametrised for different languages (Chapter 4). All gathered information and analyses are then used to create a proof-of-concept implementation (Chapter 5) that will show a possible interface for a language-parametrized REPL. The gathered results show that in order to create a full-featured language-parametrized REPL one needs a lot of additional language-specific information. This information is however already often available in language workbenches and such a REPL could therefore be easily added to any existing language workbench. 5 Chapter 2 Background 2.1 An introduction The REPL has long been recognized as a useful tool. In the scientific literature it is mainly described in two papers that each discuss the development of an IDE. Those IDEs are DrScheme, an IDE for the Lisp-dialect Scheme, and DrJava, an IDE for Java created for educational purposes. Both papers affirm the beneficial features of the REPL, they say the following about the REPL: DrJava [2] The REPL offers the advantages of \alternative entry-points", \quickly access the various components of a program without recompiling it, or otherwise modifying the program text" and \also serves as a flexible tool for debugging and testing programs and experimenting with new libraries" DrScheme [8] \Interactivity is primarily used for program exploration, the pro- cess of evaluating expressions in the context of a program to determine its behaviour. Frequent program exploration during development saves large amounts of conven- tional debugging time. Programmers use interactive environments to test small components of their programs and determine where their programs go wrong. They also patch their programs with the REPL in order to test potential improvements or bug fixes by rebinding names at the top-level." The REPL was presumably introduced in the first version of Lisp and served as a way to start running the code.