Höllische Programmiersprachen Masterseminar im Wintersemester 2014/2015 Optionale Typen Michael Lux Technische Universität München betreut durch Ralf Vogler 18.12.2014 Abstract This work is about optional typing, an approach to facilitate advan- tages of static typing like high eciency and early error detection in dy- namically typed programming languages without loosing the advantages and dynamics of the latter. As an example, it will be shown how recent JavaScript development tools make use of optional typing to facilitate those advantages in practice. 1 Introduction In the long history of software development, many programming languages be- came established. As many of them target specic application elds, whereas others are meant to be as generic as possible, there exists a broad variety of dif- ferent classes of programming languages nowadays, like imperative languages, declarative languages, object-oriented languages, or functional ones, to name just a few. One criterion, maybe one of the most obvious ones to tell dierent kinds of programming languages apart, is the so-called type system of a programming language. A type system is a syntactic method for automatically checking the absence of certain erroneous behaviors by classifying program phrases according to the kinds of values they compute. [12] Of course, there are also various type systems, but at the bottom line, all programming languages can be roughly divided into dynamically and statically typed languages [14]. Both kinds of type systems have individual advantages and disadvantages in terms of usability, type safety, performance and many more aspects. 1 This work is about usage of optional typing, an approach to bring some advantages of static typing into dynamically typed programming languages by oering an opportunity to statically dene types (either via new language constructs or via hints with normal features of the programming language) within the code whenever this is desired. Optional typing can be seen as a subsume of a number of related concepts such as gradual typing, soft typing and pluggable typing [14]. It is dicult to give an exact denition of optional typing, as the whole topic is still an active area of research [14]. In this work, the advantages and disadvantages of dynamic type systems over static type systems are briey explained rst. Secondly, two dierent approaches to introduce optional (static) types in JavaScript will be pre- sented, namely asm.js [5], a JavaScript subset for type hinting, and Flow [4], a meta-language for optional typing. Then, the focus will be on two important advantages that can be achieved using optional types: Performance improvements (or, to be more exact, improved runtime eciency) and early detection of errors (i.e. typing errors) prior to execution. Finally, the work concludes with some considerations about the usefulness of optional typing for application development, using the example of JavaScript. 2 (Dis)Advantages of Dynamic Type Systems The dierence between statically and dynamically typed languages is that the former can check the correctness of the types of variables and parameters at compile time, whereas the latter can only check those types at runtime [14]. Both statically and dynamically typed programming languages have a long, rich history. The rst programming language considered a high level programming language was FORTRAN, released in 1957 [10]. FORTRAN is, as might be intuitively assumed, a statically typed language. However, the rst dynamically typed language, LISP, was released only shortly after in 1958 [9]. This historical fact shows, that even at a time where computational power was magnitudes lower than those of today's computers, it seems that there have already been good reasons to use dynamic typing despite of it's drawbacks in terms of performance. 2.1 Advantages The rst very obvious advantage of dynamic typing is the shallower learning curve for programming beginners. Where advanced programmers are familiar with typing and related concepts, it can be quite confusing for beginners to even tell oating point numbers and integer numbers apart, not to mention type con- version, representation of boolean values or strings, and so on. Another point is the vast exibility of dynamic typing. Imagine a function that 2 sums up an array of values. In a statically typed language, one has to dene one function for each data type, e.g. one for arrays of integer values, another one for arrays of oat values, and so on. In a dynamically typed language, the function has to be written only once and can be used with any type of data that semantically makes sense. The same applies for the so-called duck typing [2], where objects with the same set of visible methods and attributes can be equally used, no matter which class they've been derived from. This leads to the nding that dynamic typing also enables, in general, faster de- velopment and ecient (i.e. fast) prototyping. For static typing, programmers always have to consider which type of data suits best for the specic applica- tion, and set up something that might be called a type contract. On the other side, when using dynamic typing, programmers can just write down the code without thinking about typing, and later adapt relevant portions of the code as required. 2.2 Disadvantages The most obvious disadvantage of dynamic typing is a loss of eciency. In statically typed languages, compilers can exploit the type information to produce more ecient code [1] and don't have to put runtime checks of types into the code. This might not be an essential issue for many applications, but it can become a problem when eciency matters, for example for scientic computing. In section 4, we will explain how optional typing can help to alleviate this issue. As dynamic type systems don't enforce types at compile time, misinter- pretation of the meaning of a function or accidental passing of wrong parameter types is also a severe issue that may result in unexpected behavior. This gets much worse when the programming language is weakly typed, i.e. does a lot of automatic type conversion based on assumptions about the most likely meaning of an expression. Let's consider a piece of JavaScript code given in Figure 1. 1 function sum(array){ 2 var sum = 0; 3 for(i = 0;i< array.length;i++) { 4 sum += array[i]; 5 } 6 return sum; 7 } 8 9 sum([1,2,3]);// result:6 10 sum(["1", 2, 3]);// result: "0123" Figure 1: sum function with invocations 3 The rst call to sum() with integer parameters yields the (most likely) expected result, the latter one might not be what the programmer expected. This happens because the + operator in JavaScript is ambiguously used for an arithmetic operation as well as string concatenation. Such errors may be xed with stronger type systems. In Python, for instance, such code would raise a TypeError, as all numeric values must be explicitly converted to strings before being concatenated there. Of course, this xes only half of the problem, as errors still can't be detected before execution. However, there are much more complex errors of this manner, like returning of null in PHP or undened in JavaScript to indicate an error, whereas the programmer expects an object and doesn't consider possible error states. It will also be shown how optional typing can help with this issue. Furthermore, as it has already been shown in Figure 1 that typing errors in dynamically typed languages can be very hard to trace and track down. Technically, the second call to the sum() function returns a perfectly valid value. This value may be further processed at dierent places and nally cause either a wrong output or a crash at some other point in time where the root cause of the failure is everything but obvious. One worst case scenario is shown in Figure 2, where the result is even forced back to the type originally expected without any hassle. Such invocations mask the error, making it almost impossible to detect the cause of wrong results. 1 sum(["1", 2, 3]) - 3;// result: 120 Figure 2: really bad invocation of sum 3 Optional Typing in Practice In the past, there has been a lot of research on how to utilize the benets of static typing in dynamically typed languages, but without integration of this approaches in any mainstream programming language [14]. However, over the past few years approaches began to emerge that try to adopt this idea in practice. This section takes a look at two of them: asm.js [5], that was developed by Mozilla and Flow [4], which was developed by facebook. 3.1 Optional Typing in asm.js Asm.js exploits the ECMAScript denitions to enforce certain native types on variables and parameters using standard JavaScript operators. For instance, ECMA-262 denes the bitwise-or-operation to be performed on 32 bit integer values, which means that an expression like x|0 corresponds to the 32 bit integer value of x. As a subset of JavaScript, it maintains full compatibility 4 to existing JavaScript interpreters according to the ECMAScript standard [6]. A very simple asm.js script is shown in Figure 3. Here, the bitwise-or-operation with the neutral element 0 is used to tell an asm.js-aware JavaScript inter- preter that the inputs as well as the return value of the function have to be 32 bit integer values. 1 function compiledCalculation(){ 2 varx=f()|0;//x isa 32-bit value 3 vary=g()|0;// so isy 4 return(x+y)|0;// 32-bit addition, no type or overflow checks 5 } Figure 3: asm.js example code This ECMAScript-compatible nota- tion comes at a cost: To take advan- tage of the speed improvements, pro- grammers must provide consistent, correct types for both input values and return values.