Scala. Functional and Object-oriented Features. Stefan Hinterkörner, Andreas Rottmann

Transcription

1 Scala Functional and Object-oriented Features Stefan Hinterkörner, Andreas Rottmann Seminar aus Informatik, SS 2010 o. Univ.-Prof. Dr. Wolfgang Pree Department of Computer Sciences, University of Salzburg July 12, 2010

2 Contents 1 Introduction 2 2 Functional Features Proper tail recursion Functions as first-class Values Syntactic Sugar Closures Currying and Control Abstraction Conclusion Object-oriented Features Abstract classes Extending classes Overriding methods and fields Traits Scala in the Real World Framework: Lift Application: Twitter

3 1 Introduction In this paper, we present a selection of advanced concepts of the Scala programming language. The reader is assumed to have some experience in Java, and preferably a basic understanding of Scala syntax. Scala is covered in detail in its de-facto reference [5]. In particuliar, the topics covered in the following are discussed by [5] in Chapters 8, 9, 10 and 12. We conclude with Section 4, giving two examples of Scala usage in the real world. 2

4 2 Functional Features Before looking at the features that make Scala worthy of the predicate functional programming language, it is illustrative to have a short look at what exactly constitutes the functional programming paradigm. Essentially, a functional language emphasizes the application of functions over the explicit manipulation of state, as is the case with imperative programming languages. The use of assignment statements to change the implicit state of a program is a primary symptom of an imperative programming style. A functional program, on the other hand, explicitly passes state around, and eschews assignment statements completely [3]. Clearly, Scala supports the imperative style, inheriting from the Java tradition, but it also allows for a functional style. For example, consider the imperative and functional implementations of the factorial given in Figure 1 and Figure 2, respectively. Note that the functional definition of factorial does not use assignment statements, only variable binding; all variables occurring in the program are immutable vals, whereas the imperative version relies on mutation and vars. Another notable thing about the functional version is the use of the local, nested function definition fact, a feature that is not available in Java. def factorial(n: Int) = { var result = 1; var i = n; while (i > 0) { result = result * i i = i - 1 result; Figure 1: Imperative factorial 2.1 Proper tail recursion An attentive reader will have noticed that the local function fact is recursive, and may have wondered about the space and time overhead; after all, each recursive call will need to allocate a stack frame and also be more expensive 3

5 def factorial(n: Int) = { def fact(acc: Int, n: Int): Int = { if (n > 0) fact(n * acc, n - 1) else acc fact(1, n) Figure 2: Functional factorial in terms of time than the jump implied by the while loop in the imperative version, right? Actually, neither is the case for this example: the Scala compiler will eliminate the recursion, thus yielding equivalent performance characteristics for both programs. This important optimization can only be applied in special circumstances, however: 1. The recursive call must be the final expression to be evaluated in the function; there must be no further work remaining to be done before the function returns. This is also referred to as the call being in tail position. 2. The call must be directly recursive, calls to other functions will indeed require stack frame allocation, even if they are in tail position. The first of these requirements is fundamental: a stack frame needs to be created if there is further work to be done inside the calling function, otherwise the calling function could not be resumed after the called function has returned. The second requirement, however, is a limitation of Scala (or, to be fair, of the underlying Java Virtual Machine); in languages like ML[4] or Scheme[1], this restriction is lifted, and all calls in tail position are optimized. 2.2 Functions as first-class Values Another hallmark of functional languages, besides their disregard for mutability, is that they elevate functions into first-class citizen status: functions 4

6 can be treated just like any other value, for example, they can be passed as arguments to other functions and can be stored in data structures. The following example shows the syntax for expressing function literals; they are written as the type signature of the function followed by an arrow (=>) and the body of the function: val add3 = (x: Int) => x + 3 add3(4) // evaluates to 7 This syntax allows for the concise specialization of a general function by passing it appropriate functions as parameters. For instance, to find all numbers divisible by three in a Scala collection, one can use the filter method of the Iterable trait 1, which will return a new Iterable containing only elements matching the predicate passed to it: val input = List(2, 3, 5, 6, 7, 9) val result = input.filter((x: Int) => x % 3 == 0) In the above example, result will contain 3, 6 and 9. Another illustration for the power and usefulness of first-class functions is given in Figure 3, which could be part of a simple calculator, where run-time lookup of operators is needed. val builtinops = Map("+" -> ((x: Int, y: Int) => x + y), "-" -> ((x: Int, y: Int) => x - y), "*" -> ((x: Int, y: Int) => x * y), "/" -> ((x: Int, y: Int) => x / y)) builtinops("*")(6, 7) // evaluates to 42 Figure 3: A map containing functions Syntactic Sugar Scala allows for some ways to shorten the notation of function literals: In certain contexts, Scala can infer the parameter types, hence the types can be left out in these cases. The parentheses around a parameter whose type is inferred may be omitted. 1 Traits will be discussed in more detail in Section

7 Placeholder syntax allows parameters in the body of a function literal to be replaced by underscores, and the parameter list and arrow to be omitted. This is only feasible when each parameter occurs once in the body, of course. _ + _ // is the same as: (x, y) => x + y Partially applied functions are a way derive a function from an existing function by fixing some of its parameters: def max(x:int, y:int) = if (x > y) x else y val atleast5 = max(_: Int, 5) atleast5(4) // results in 5 atleast5(42) // results in 42 One can also specify a placeholder for the whole argument list using the following syntax: List(1, 2, 3).foreach(println _) Note the omission of the parentheses around the underscore Closures Scala also supports closures, functions that refer to variables from their enclosing scope or scopes. An example is provided in Figure 4. Similiar to the code given above, it finds multiples of a given number, however this time the number is not a constant, but a variable defined in an outer scope. The function expression is said to close over (or be a closure over) the variable n. A closure can also be returned from a function, as in Figure 5. In this case, the variables closed over have an extent (lifetime) that exceeds the duration of the call to the function that declares them. In Figure 5, the variable amount is available to the closure after makeadder has returned. Closures can be used to encapsulate state, similiar to a class instance. There is a saying, Classes are a poor man s closures, attributed to Norman Adams in a paper by Kenneth Dickey[2], which shows how once you have closures, 2 In most functional languages, there is no special syntax needed for this case, as you can just pass the function itself as an argument, without having to construct a partially applied function. See [5], Section 8.7 for a rationale of why the trailing underscore is needed in Scala. 6

8 def multiples(n: Int, collection: Iterable[Int]) = { collection.filter((x: Int) => x % n == 0); val result = multiples(3, List(2, 3, 5, 6, 7, 9)) def makeadder(amount: Int) = { (x: Int) => x + amount val add3 = makeadder(3) add3(4) // evaluates to 7 Figure 4: A closure in action Figure 5: Returning a closure you can implement a variety of Object Models, including classical ones like the one found in Java. We ll leave aside how to implement inheritance and other advanced concepts, and just provide a small example to illustrate state encapsulation with closures. Figure 6 shows a simple counter, implemented as a single-method Scala class, while Figure 7 shows the same mechanism implemented with a closure. Note that like in makeadder above, makecounter returns a closure, but this time it closes over the var counter and mutates that, in the same way the count method mutates the instance variable counter. In fact, with a bit of squinting, the closure version looks almost the same as the class-based version. 2.4 Currying and Control Abstraction Currying in Scala allows the programmer to write functions returning functions in a more concise way; instead of specifying a single argument list for a function, multiple ones may be specified. In Figure 8, the curried function curriedtimes is defined, then fully applied to compute a numerical result. After that, it is partially applied (only the first argument list is specified), yielding a function that will multiply its argument by three. Curried functions are employed in Scala to facilitate writing new control abstractions that look like being built right into the language. As Scala allows 7

9 class Counter(start: Int) { var counter = start def count() = { val result = counter counter = counter + 1 result val c1 = new Counter(0) val c2 = new Counter(5) for (i <- 1 to 3) { println("c1.count() = " + c1.count()) println("c2.count() = " + c2.count()) Figure 6: A simple counter class Figure 7: A counting closure def makecounter(start: Int): () => Int = { var count = start () => { val result = count count = count + 1 result val c1 = makecounter(0) val c2 = makecounter(5) for (i <- 1 to 3) { println("c1() = " + c1()) println("c2() = " + c2()) 8

10 def curriedtimes(x: Int)(y: Int) = x * y curriedtimes(6)(7) // evaluates to 42 val times3 = curriedtimes(3)_ times3(5) // evaluates to 15 Figure 8: A curried function parentheses to be replaced by curly brackets for argument lists that consist of a single argument, and curried functions can be used to break the argument list into pieces, natural-looking control abstractions can be written. For example, consider Figure 9, which implements a function withlock that executes an operation during which the specified lock is acquired. This example uses a further syntactic feature of Scala, by-name parameters, which allows leaving out an empty parameter list in a function signature, as is the case with op in the example. See [5], Section 9.5, more information about by-name parameters. import scala.concurrent.lock def withlock(lock: Lock)(op: => Unit) { lock.acquire try { op finally { lock.release val lock = new Lock() withlock(lock) { println("hello World!") Figure 9: Control abstraction 2.5 Conclusion Scala offers a range of features, most importantly first-class functions, that allow programming in a functional style, making Scala a multiple-paradigm 9

11 language. Using functional style makes reasoning about programs easier by avoiding manipulation of implicit state. Moreover, Scala allows for easy and concise expression of concepts such as new control operators which are not directly expressible in languages without support for functional programming (like Java). 10

12 3 Object-oriented Features This chapter will explain some advanced object-oriented aspects of Scala. First of all we will explore the differences between Java and Scala in Abstract classes, Overriding of methods/fields and Inheritance. The last section will explain so called Traits, a special variant of Mixins introduced in Scala. 3.1 Abstract classes Abstract classes are identified by the abstract modifier. It is written prior the class keyword and ensures that abstract classes cannot by instantiated. Abstract classes must have only declared methods. From this it follows that methods are not allowed to have an implementation. There is one exception to this rule: Parameterless methods. As you can see in Figure 10 the method height is implemented. Parameterless methods should be used whenever there are no parameters for the method and even more important, the method only reads fields of the containing object. Those methods are comparable to Java getter methods. We could write parameterless methods with parentheses, but if we leave the parentheses out we indicate that the method has no side-effect. abstract class Element { def contents: Array[String] def height: Int = contents.length Figure 10: Basic structure of an abstract class [5] 3.2 Extending classes To make a subclass of another class, like in Java, the extends keyword is used. When a plain class is written without inheriting any other class, Scala implicitly uses AnyRef. AnyRef is the root class of all Scala classes. If we create a subclass we have to note that private members of the superclass and members with the same name and parameters already implemented in the subclass are not inherited. Figure 11 demonstrates how we implement a subclass of our abstract class defined in the previous Figure. Now we are able to create an object out of the 11

13 new class with our methods defined in the superclass. Class ArrayElement is a subclass of Element and so we can use Subtyping to create a new object. class ArrayElement(conts: Array[String]) extends Element { def contents: Array[String] = conts val elem: Element = new ArrayElement(Array("hello")) Figure 11: Inheritance in Scala [5] 3.3 Overriding methods and fields In Scala fields and methods belong to the same namespace, i.e. if you have a superclass with a method write, you could simply override this method in a subclass with a field write. Thus it s not possible to define a field and method with the same name in the same class. To invoke superclass constructors we have to pass the parameters of the subclass to the superclass. This is done by placing the parameters in parentheses after the superclass name. In Scala we use the modifier override to override members of the superclass. It s compulsory and so almost solves the fragile base class problem. If you have a subclass with a method called test and later you add a method test to the superclass, the subclass will not compile. Thereupon you will notice that you have to check the subclass method and, if necessary, refactor it. Figure 12 is an excellent example to explain overriding in Scala and to demonstrate how well Java and Scala are working together. The example, written by Daniel Spiewak[7], shows us a Scala class StrikeLabel, which inherit from the Java class JLabel. It will display Text that is crossed out with a red line. As we can see in the first line, StrikeLabel passes the default constructor parameter text to the JLabels default constructor. Furthermore it invokes the default constructor with an empty String, if text is empty. Therefore it uses the this keyword. JLabel defines a method paintcomponent which takes a Graphics object as parameter. StrikeLabel overrides this method and invokes the superclass method by using the keyword super. 12

14 class StrikeLabel(text:String) extends JLabel(text) { def this() = this("") override def paintcomponent(g:graphics):unit = { super.paintcomponent(g) g.setcolor(color.red) g.drawline(1, getheight() / 2, getwidth() - 1, getheight() / 2) Figure 12: Mixing Scala Code with Java [7] 3.4 Traits Scala has its own special implementation of Mixins called Traits. A Mixin is a unit of functionality, which can be added to a class. A trait has to have the same base class as the class which uses the trait. Like in multiple inheritance a class can use any number of traits. Unlike multiple inheritance, traits do not cause a diamond problem because of linearization. We will see what linearization and traits are in the following example (inspired by Spiewak [7]). First we discuss the Java code in Figure 13 and later we will see the improved version written in Scala. Our starting point is an abstract class called Vehicle. It has a method getengine which returns the vehicles engine. Furthermore there are two interfaces called ICar and IPlane. Obviously ICar is able to drive and IPlane is able to fly. The class Car inherits from our abstract class Vehicle and implements interface ICar. Car has an engine and can drive. Plane is also a vehicle with an engine and has the ability to fly. Because we are enthusiastic drivers and pilots, so we want a flying Car. To build our FlyingCar we have to implement both interfaces IPlane and ICar. Skilled developers have already identified some code smells. First of all we have to implement the methods drive and fly multiple times. That s unpopular code duplication. Secondly the hierarchy is already a little bit complicated. In bigger application this can become confusing very fast. And lastly, its possible to create a Car or Plane without being a Vehicle. Looking at the Scala code in Figure 14 we see that there is also have an abstract class called Vehicle. Instead of the two interfaces we now have two traits. Traits inherit from a base class. In our case the base class is Vehicle. 13

15 public abstract class Vehicle { public abstract Engine getengine(); public interface ICar { public void drive(); public interface IPlane { public void fly(); public class Car extends Vehicle implements ICar { private Engine carengine; public Car(TyreType type) {... public Engine getengine() { return carengine; public void drive() {... public class Plane extends Vehicle implements IPlane { private Engine planeengine; public Plane(WingType type) {... public Engine getengine() { return planeengine; public void fly() {... public class FlyingCar extends Vehicle implements IPlane, ICar { public FlyingCar(WingType wingtype, TyreType tyretype) {... public Engine getengine() {... public void fly() {... public void drive() {... Figure 13: Java example 14

16 Both traits have their own engine. Trait car has an implemented method drive and trait Plane has a method fly. To create our FlyingCar we mix in both Traits. That s the point where linearization comes into play. Our FlyingCar has now two engines. One from Plane and the other one from Car. Which one will be used? Scala interprets traits from right to left. So, in the first example, the engine from Car is used because we mix in Car after Plane. In the other example, the engine from Plane is the winner. With the keyword with we can mix in as many traits as we want. There is one minor detail: Traits cannot have any class parameters. 15

17 abstract class Vehicle { def engine:engine trait Car extends Vehicle { private var carengine:engine =... override def engine = carengine def drive() = {... trait Plane extends Vehicle { private var planeengine:engine =... override def engine = planeengine class def fly() = {... FlyingCar(wingType:WingType, tyretype:tyretype) extends Plane with Car { class // engine from Car FlyingCar(wingType:WingType, tyretype:tyretype) extends Car with Plane { // engine from Plane Figure 14: Scala example 16

18 4 Scala in the Real World Learning a new programming language can be a waste of time, if the language disappears from the scene after a while. Existing frameworks and application with a active community can give you a reliable prediction about the future of a language. Scala is still young and has not (yet) a big community as other languages. However there are the well known Webframework Lift and the famous microblogging service Twitter. Both are (partly) written in Scala. 4.1 Framework: Lift Lift[6] is a Webframework fully written in Scala. Founder David Pollak has invented Lift to get an elegant framework for writing web applications. Because Lift is written in Scala you can use Java APIs and deploy your web application to a Servlet Container (e.g. Tomcat). By way of example location-based social networking website Foursquare is written in Lift. It is now available in Version 2 and licensed under the Apache 2.0 License. 4.2 Application: Twitter Social network Twitter was originally implemented in Ruby on Rails. It still uses Ruby on Rails for the web application, but the back-end services were replaced with Scala applications. Due to performance limitations at runtime the Twitter developers decided to switch. Main advantages they mentioned are basically the advantages of the JVM (Threads, long lived processes, Garbage collector, JIT,...) and the easy to maintain Scala Code with it s functional features. An interview with three Twitter developers can be read on artima.com[8]. 17

19 References [1] N. I. Adams, IV, D. H. Bartley, G. Brooks, R. K. Dybvig, D. P. Friedman, R. Halstead, C. Hanson, C. T. Haynes, E. Kohlbecker, D. Oxley, K. M. Pitman, G. J. Rozas, G. L. Steele, Jr., G. J. Sussman, M. Wand, and H. Abelson. Revised5 report on the algorithmic language scheme. SIGPLAN Not., 33(9):26 76, [2] Kenneth Dickey. Scheming with objects. ftp://ftp.cs.indiana.edu/ pub/scheme-repository/doc/pubs/swob.txt, [Online; 11. Juli 1010]. [3] Paul Hudak. Conception, evolution, and application of functional programming languages. ACM Comput. Surv., 21(3): , [4] Robin Milner, Mads Tofte, and David Macqueen. The Definition of Standard ML. MIT Press, Cambridge, MA, USA, [5] Martin Odersky, Lex Spoon, and Bill Venners. Programming in Scala: A Comprehensive Step-by-step Guide [6] David Pollak. Lift webframework [Online; 6. Juli 2010]. [7] Daniel Spiewak. Scala for java refugees. blog/scala/scala-for-java-refugees-part-3, [Online; 6. Juli 2010]. [8] Bill Venners. Twitter on scala. articles/twitter_on_scala.html, [Online; 6. Juli 2010]. 18