序文

本書は、はじめて Scala を学ぶプログラマーを対象にしています。Java のようなオブジェクト指向プログラミング言語にある程度精通していることを前提としていますが、関数型プログラミングについての経験は前提としていません。

本書のゴールは最小限の Scala の使い方を説明することです。そのため、Scala コードにおいてイディオムとして使用される重要パターンに焦点をあて、Scala の機能が実現可能にするそれらパターンの文脈で、Scala の機能自体を紹介していきます。Scala の機能を網羅することを目的とはしていませんし、本書はリファレンスマニュアルでもありません。

いくつかの演習を除いて、外部ライブラリには一切依存していません。本書に含まれるすべての問題は、テキストエディターと Scala の REPL、もしくは、Scala IDE for Eclipse や IntelliJ IDEA のような IDE で完成させることができます。

Scala 入門 (Essential Scala) は、Underscore の Noel Welsh と Dave Gurnell によって生み出されました。それは、Underscore’s eBook Template とプレーンテキスト、関数型プログラミングへの深い愛情を使用して構築されました。

本書で使用している規則

本書には、たくさんの技術情報とプログラムコードが含まれます。曖昧さを減らし、重要な概念を強調するために、下記のような組版規則を使用します。

組版規則

新しい用語やフレーズは太字で紹介されます。（訳注：原書では斜体ですが、訳書では視認性の高い太字を使用します。）最初に紹介されたあとは、通常の字体で書かれます。

プログラムコード由来の用語やファイル名、ファイルの内容は等幅フォントで記述します。単数形と複数形を区別しないことに注意してください。例えば、String や Stirngs と書いたものは java.util.String クラスやその型のオブジェクトを参照します。（訳注：日本語訳ではすべて単数形に統一しています。）

外部リソースへの参照はハイパーリンクとして記述します。API ドキュメントへの参照は、Option のように、ハイパーリンクと等幅フォントの組み合わせを使用して記述します。

ソースコード

ソースコードブロックは下記のように記述されます。文法は必要に応じて適切にハイライトされます。

object MyApp extends App {
  println("Hello world!") // ユーザーへの素晴らしいメッセージを印字する！
}

プログラムコードのいくつかの行は、ページに収めるには広すぎるものがあります。そのような場合には、すべてを1行で書かれるべき長いコードであることを示すために、折れた矢印の継続文字 (continuation character) を使用します。例えば、下記のようなコードを、

println("This code should all be written ↩
  on one line.")

実際は、下記のように書かれなければなりません。

println("This code should all be written on one line.")

コールアウトボックス

本書では、特別な内容を強調するために、3種類のコールアウトボックス (callout box) を使用します。

Thanks

Many thanks to Richard Dallway and Jonathan Ferguson, who took on the herculean task of proof reading our early drafts and helped develop the rendering pipeline that produces the finished book.

Thanks also to Danielle Ashley, who updated all of the code samples to use Tut and increased our code quality 100% overnight!

Thanks also to Amir Aryanpour, Audrey Welsh, Daniel Watford, Jason Scott, Joe Halliwell, Jon Pearce, Konstantine Gadyrka, N. Sriram, Rebecca Grenier, and Raffael Dzikowski, who sent us corrections and suggestions while the book was in early access. Knowing that our work was being used made the long haul of writing worthwhile.

1 はじめに

本書では、Scala コードの短い例を使って学んでいきます。それには2つの推奨される方法があります。（訳注：訳書において Scala IDE を使用する方法は非推奨です。理由は「Scala IDE を準備する」の節に記載しています。）

1. Scala コンソール (Scala console) を使用する（コマンドラインが好きな人にはよいでしょう）

2. Scala IDE の ワークシート (worksheet) を使用する（IDE が好きな人にはよいでしょう）

ここでは、それらを準備するための各工程を一通り説明していきます。

1.1 Scala コンソールを準備する

http://scala-lang.org の手順に従って、コンピューターに Scala を設定します。一度 Scala がインストールされれば、コマンドラインプロンプトで scala と入力することで、対話的なコンソールを実行できるようになるはずです。これは macOS の例です。（訳注：内容を2020年現在のものに修正しています。）

dave@Jade ~> scala
Welcome to Scala 2.13.1 (OpenJDK 64-Bit Server VM, Java 1.8.0_242).
Type in expressions for evaluation. Or try :help.

scala>

scala> プロンプトで個々の式を入力し、Enter キーを押下することで、それらをコンパイルし、実行することができます。

scala> "Hello world!"
res0: String = Hello world!

1.1.1 一行の式を入力する

単純な式を入力してみましょう。

scala> 1 + 2 + 3
res1: Int = 6

Enter キーを押下したとき、コンソールは3つのことを応答します。

• 識別子 (identifier) res1
• 型 (type) Int
• 値 (value) 6

次章で見ていくように、Scala のすべての式は 型 と 値 を持ちます。型はコンパイル時に決定され、値は式を実行するときに決定されます。ここでは、その両方が報告されています。

識別子 res1 は、式の結果を将来の式の中で参照できるように、コンソールが提供する便利なものです。例えば、下記のように先ほどの結果を2倍することができます。

scala> res1 * 2
res2: Int = 12

有用な値を生成しない式を入力すると、コンソールは応答として何も印字しません。

scala> println("Hello world!")
Hello world!

ここで、"Hello world!" という出力は println という記述に由来しています。入力した式は実際のところ値を返しません。コンソールは上記で見た出力に類するものを提供していないのです。

1.1.2 複数行の式を入力する

簡単に複数行に渡る長い式を分割することができます。式が終わる前に Enter キーを入力すると、コンソールは次の行に継続していることを示す | という文字を印字します。

scala> for(i <- 1 to 3) {
     |   println(i)
     | }
1
2
3

一度に複数行の式を入力したいことがあります。このような場合、:paste コマンドを使用することができます。単純に :paste と入力し、Enter キーを押下し、コードを記述もしくはコピー＆ペーストしてください。すべてを入力し終わったら Ctrl+D を押下してください。通常のようにコードのコンパイルと実行がされます。

scala> :paste
// Entering paste mode (ctrl-D to finish)

val x = 1
val y = 2
x + y

// Exiting paste mode, now interpreting.

x: Int = 1
y: Int = 2
res6: Int = 3

ファイルに Scala コードがあるのであれば、ファイルの内容をコンソールの中に貼り付けるために :paste を使用できます。これは、コンソールに式を再入力するよりはるかに便利です。例えば、1 + 2 + 3 を含む example.scala という名前のファイルがあるとき、下記のように :paste を使用できます。

scala> :paste example.scala
Pasting file example.scala...
res0: Int = 6

1.1.3 式の型を印字する

コンソールを使用する上での最後のテクニックです。時々、式を実際に実行せずに、その型を知りたいことがあります。それをするために、:type コマンドを使用することができます。

scala> :type println("Hello world!")
Unit

コンソールは、この式の println という記述を実行しないことに注意してください。コードをコンパイルし、この場合は Unit と呼ばれる何らかの型を印字しているだけです。

Scala の Unit は Java や C の void と同じです。詳細は第2章を読んでください。

1.2 Scala IDE を準備する

Scala IDE is a plugin that adds Scala language support to Eclipse. A complete version of Scala IDE with Eclipse is also available as a standalone bundle from http://scala-ide.org. This is the easiest way to install the software so we recommend you install the standalone bundle for this course.

Go to http://scala-ide.org now, click the Get the Bundle button, and follow the on-screen instructions to download Scala IDE for your operating system:

Once you have downloaded and uncompressed the bundle you should find an application called Eclipse. Launch this. You will be asked to choose a folder for your workspace:

Accept the default location and you will see an empty main Eclipse window:

1.2.1 Creating your First Application

Your Eclipse workspace is two things: a folder containing files and settings, and a main window where you will be doing most of your Scala programming. In your workspace you can find projects for each Scala application you work on.

Let’s create a project for the book exercises now. Select the File menu and choose New > Scala Project:

Enter a Project name of essential-scala and click Finish. The tree view on the left of your workspace should now contain an empty project:

A project is no good without code to run! Let’s create our first simple Scala application - the obligatory Hello World app. Select the File Menu and choose New > Scala Object:

Name your object HelloWorld and click Finish. A new file called HelloWorld.scala should appear in the tree view on the left of the main window. Eclipse should open the new file in the main editor ready for you to start coding:

The content of the file should read as follows:

object HelloWorld {

}

Replace this text with the following minimalist application:

object HelloWorld {
  def main(args: Array[String]): Unit = {
    println("Hello world!")
  }
}

Select the Run Menu and choose Run. This should execute the code in your application, resulting in the words Hello world! appearing in the Console pane at the bottom of the window. Congratulations - you just ran your first Scala application!

Developers with Java experience will notice the resemblance of the code above to the Java hello world app:

public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello world!");
  }
}

The resemblance is, of course, no coincidence. These two applications compile to more or less the same bytecode and have exactly the same semantics. We will learn much more about the similarities and differences between Scala and Java as the course continues.

1.2.2 Creating your First Worksheet

Compiling and running code whenever you make a change is a time consuming process that isn’t particularly suitable to a learning environment.

Fortunately, Scala IDE allows us to create special files called Scala Worksheets that are specifically designed for training and experimentation. Every time you save a Worksheet, Eclipse automatically compiles and runs your code and displays the output on the right-hand side of your editor. This provides instant feedback, which is exactly what we need when investigating new concepts!

Create your first Scala Worksheet by selecting the File Menu and choosing New > Scala Worksheet:

Enter a Worksheet name of FirstSteps and click Finish. A new file called FirstSteps.sc should appear in the tree view on the left of the main window, and should open it in the main editor in the middle:

Note that the object on the left contains a single line of Scala code:

println("Welcome to the Scala worksheet")

for which Eclipse is displaying the corresponding output on the right:

Welcome to the Scala worksheet

Any expression you add to the left of the editor is evaluated and printed on the right. To demonstrate this, change the text in the editor to the following:

object FirstSteps {
  println("Welcome to the Scala worksheet")

  1 + 1

  if(20 > 10) "left" else "right"

  println("The ultimate answer is " + 42)
}

Save your work by selecting the File Menu and choosing Save (or better still by pressing Ctrl+S). Eclipse should automatically evaluate each line of code and print the results on the right of the editor:

object FirstSteps {
  println("Welcome to the Scala worksheet")   //> Welcome to the Scala worksheet

  1 + 1                                       //> res0: Int(2) = 2

  if(20 > 10) "left" else "right"             //> res1: String = left

  println("The ultimate answer is " + 42)     //> The ultimate answer is 42
}

We’ll dive into what all of the text on the right means as we proceed with the course ahead. For now you’re all set to start honing your Scala skills!

2 式・型・値

本章では Scala プログラムの基本的な構成要素である式 (expression)・型 (type)・値 (value) について見ていきます。それらのコンセプトを理解することが Scala プログラムがどのように動くのかというメンタルモデルを形成するために必要です。

2.1 最初のプログラム

Scala コンソールか Scala ワークシートに "Hello world!" と入力し、コンソールでリターンキーを押下するかワークシートを保存してください。このようなインタラクションが見られるはずです。

"Hello world!"
// res0: String = Hello world!

このプログラムについてはいろいろ言えることがあります。それは特別にリテラル式 (literal expression) もしくは略してリテラルと呼ばれる単一の式で構成されていることです。

Scala は私たちのプログラムを実行（評価）します。Scala コンソールや Scala ワークシートでプログラムを評価するとき、プログラムの型とプログラムを評価した値という2つの情報を受け取ります。この場合は、型が String で、値が "Hello world!" です。

プログラムが生成した出力値 “Hello world!” はプログラムと同じに見えますが、その2つの間には違いがあります。リテラル式は入力したプログラムテキストである一方、コンソールが表示したものはプログラムを評価した結果です。（リテラル (literal) は、評価されたものがその文字通り (literally) に見えるので名付けられました。）

わずかに複雑なプログラムを見てみましょう。

"Hello world!".toUpperCase
// res1: String = HELLO WORLD!

このプログラムはメソッド呼び出し (method call) を加えることによって最初の例を拡張したものです。Scala における評価は左から右へ進みます。この例では、最初にリテラル "Hello world!" が評価されます。次に、その評価された結果に対しメソッド toUpperCase が呼ばれます。このメソッドは文字列値を大文字に変換したものを新しい文字列として返します。これがコンソールによって表示された最終的な値です。

繰り返しになりますが、このプログラムの型は String で、この場合はプログラムが "HELLO WORLD!" に評価されます。

2.1.1 コンパイル時と実行時

Scala プログラムが通過する明確な2つの段階があります。最初がコンパイル (compile) で、コンパイルが成功していれば、次が実行 (run) または評価です。最初のステージをコンパイル時 (compile-time)、次のステージを実行時 (run-time) と呼びます。

Scala コンソールを使用しているとき、プログラムはコンパイルしてすぐに評価されるので、1つの段階だけがあるような印象を抱かせます。型と値の間における違いを正しく理解するためにも、コンパイル時と実行時がまったく異なることを理解するのは重要です。

コンパイルはプログラムが意味をなしているかを検証する工程です。プログラムが「意味をなす」には2つの観点が必要です。

1. プログラムは文法的に正確 (syntactically correct) でなければなりません。それはプログラムの部品が言語の文法に従っているということを意味します。“on cat mat sat the”（猫の上敷き物座った）は文法的に正確ではない英文の例です。これは文法的に正確ではない Scala プログラムの例です。

toUpperCase."Hello world!"
// <console>:2: error: identifier expected but string literal found.
// toUpperCase."Hello world!"
//             ^

2. プログラムは型検証 (type check) されなければなりません。意味をなすプログラムであるということは、プログラムがある制約に従っているということを意味します。“the mat sat on the cat”（敷き物は猫の上に座った）は文法的に正確ですが意味がわからない英文の例です。これは数値を大文字に変換しようとして型検証に失敗するシンプルなプログラムです。

2.toUpperCase
// <console>:13: error: value toUpperCase is not a member of Int
//        2.toUpperCase
//          ^

大文字小文字という概念は数値について意味をなさないので、型システムはこのエラーを捕捉します。

プログラムがコンパイル時の検証を通過した場合、次にプログラムは実行されるかもしれません。実行はコンピューターがプログラムにある指示を実行する工程です。

プログラムのコンパイルが成功したとしても、実行時に失敗する可能性が残っています。整数を0で割ると Scala では実行時エラーが発生します。

2 / 0
// java.lang.ArithmeticException: / by zero
//   ... 342 elided

整数の型 Int はプログラムの型検証を通過すれば割り算できます。しかし、割り算の結果を表現できる Int が存在しないので、実行時にプログラムは失敗します。

2.1.2 式・型・値

それでは、式・型・値とは正確には何でしょうか？

式はファイルやコンソール、ワークシートに入力したプログラムテキストの一部です。それは Scala プログラムの主要な構成要素です。のちほど、定義 (definition) や文 (statement) と 名付けられた他の構成要素も見ていきます。式はコンパイル時に存在します。

式の特徴を定義すると、それは値に評価されるということです。値はコンピューターのメモリに保持されます。それは実行時に存在します。例えば、式 2 は、コンピューターのメモリの、特定の場所の、特定のビット列に評価されます。

私たちは値を用いて計算します。値はプログラムが受け渡したり操作したりする実体です。例えば、2つの数値の最小値を計算するために、下記のようなプログラムを書くでしょう。

2.min(3)
// res4: Int = 2

ここに2つの値 2 と 3 があり、それらを 2 に評価されるより大きなプログラムに結合しています。

Scala において、すべての値はオブジェクト (object) で、のちほど見ていくように特定の意味を持ちます。

さて次に型のことを考えましょう。型はプログラム上の制約で、どのようにオブジェクトを操作できるかを制限します。すでに2つの型 String と Int を、そして型によって異なる操作を実行できることを見てきました。

この段階で、型についてもっとも重要な点は式は型を持つが値は持たないということです。私たちはコンピューターのメモリの任意の部分を検査できませんし、それを生成したプログラムを知らずして、どのようにそれが解釈されるのかを予言できません。例えば、Scala で Int 型と Float 型はどちらもメモリの32ビットによって表現されます。しかし、与えられた32ビットを Int や Float として解釈すべきというタグやその他の表示はないのです。

実行時エラーを引き起こす式の型を教えてと、Scala コンソールに尋ねることによって、コンパイル時に型が存在することを明らかにできます。

:type 2 / 0
// Int

2 / 0
// java.lang.ArithmeticException: / by zero
//   ... 486 elided

式 2 / 0 は、それを評価したときには失敗するにも関わらず、Int 型を持つことを見ました。

コンパイル時に存在する型は、値に一貫した解釈を与えるプログラムを書くように制約します。特定の32ビットが、ある時は Int で、またある時は Float であると断言はできません。プログラムの型が検証されたとき、Scala はすべての値が一貫して使用されることを保証するので、値の表現で型の情報を記録する必要がありません。型の情報を取り除くこの処理を型消去 (type erasure)¹と呼びます。

必然的に、型に合致する値について、考え得るすべての情報をその型は含みません。そうしないと、型検証はプログラムを実行することと等価になってしまいます。すでに見てきたように、型システムは Int をゼロで割ることを防ぐことはなく、それは実行時エラーを引き起こします。

Scala コード設計の主要部分は、型システムの利用において、どのエラーケースを無視したいのかを決定することです。型システムでたくさんの便利な制約を表現することで、プログラムの信頼性を向上させられることを見ていきます。もしプログラムにおいて十分に重要であると決定すれば、エラーの可能性を表現する型システムを使用した除算演算子を実装することができます。型システムを上手に使用することは本書における重要なテーマのひとつです。

2.1.3 覚えておいてほしいこと

Scala を使用するのであれば、Scala プログラムのメンタルモデルを構築しなければなりません。このモデルにおける3つの基本的な構成要素は式・型・値です。

式は値に評価されるプログラムの部品です。Scala プログラムの主要な部品になります。

式は型を持ち、プログラムの制約を表現します。コンパイル時にプログラムの型は検証されます。型に一貫性がない場合、コンパイルは失敗し、プログラムを評価（実行）することはできません。

値はコンピューターのメモリに存在し、実行中のプログラムが操作するものです。Scala におけるすべての値はオブジェクトで、その意味はのちほど議論します。

2.1.4 演習

2.1.4.1 型と値

Scala コンソールか Scala ワークシートを使用して、下記の式の型と値を特定してください。

1 + 2

"3".toInt

"foo".toInt

println("foo")
// foo

println("foo".toInt)
// java.lang.NumberFormatException: For input string: "foo"
//   at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
//   at java.lang.Integer.parseInt(Integer.java:580)
//   at java.lang.Integer.parseInt(Integer.java:615)
//   at scala.collection.immutable.StringLike$class.toInt(StringLike.scala:272)
//   at scala.collection.immutable.StringOps.toInt(StringOps.scala:29)
//   ... 730 elided

2.2 オブジェクトとの相互作用

前節では Scala プログラムの基本的な構成要素である式・型・値を見てきました。また、すべての値はオブジェクトであることも学びました。本節では、オブジェクトとオブジェクトに対してどのように相互作用するのかについて学んでいきます。

2.2.1 オブジェクト

オブジェクトはデータとそのデータへの操作のグループです。例えば、2 はオブジェクトです。データは整数の2で、データへの操作はなじみのある + や - などです。

オブジェクトのデータと操作について特別な専門用語があります。操作はメソッド (method) として知られています。データはフィールド (field) に保持されます。

2.2.2 メソッド呼び出し

メソッド呼び出し (call) によってオブジェクトを作用させます²。メソッド呼び出しの例をいくつかすでに見てきました。例えば、String の大文字版をその toUpperCase メソッドを呼び出すことによって取得できることを見ました。

"hello".toUpperCase
// res0: String = HELLO

一部のメソッドは引数 (parameter) を受け取り、それはメソッドがどのように動作するかを制御します。例えば、take メソッドは String から文字を取り出します。いくつの文字を取り出したいかを指定する引数を take に渡す必要があります。

"abcdef".take(3)
// res1: String = abc

"abcdef".take(2)
// res2: String = ab

anExpression.methodName(param1, ...)

anExpression.methodName

メソッド呼び出しは式なのでオブジェクトに評価されます。これは、より複雑なプログラムをつくるために、メソッド呼び出しを連鎖できるということを意味します。

"hello".toUpperCase.toLowerCase
// res3: String = hello

メソッド呼び出しにおける様々な式はどの順番で評価されるのでしょうか？メソッド引数は、メソッドが呼び出される前に左から右に評価されます。下記の式では、

"Hello world!".take(2 + 3)
// res4: String = Hello

最初に式 "Hello world!" が、次に 2 + 3（これは、最初に 2 を、次に 3 を評価する必要があります。）が、そして最後に "Hello world!".take(5) が評価されます。

2.2.3 演算子

Scala においてすべての値はオブジェクトであるため、Int や Boolean のようなプリミティブ型についてもメソッドを呼び出すことができます。これは int や boolean がオブジェクトではない Java と対照的です。

123.toShort // これは Scala で `Short` を定義する方法です
// res5: Short = 123

123.toByte // これは `Byte` を定義する方法です
// res6: Byte = 123

しかし、Int がオブジェクトであれば、+ や - のような基本的な算術演算子は何でしょうか？それらもまたメソッドでしょうか？そうです。Scala のメソッドは英数字の名前と同じようにシンボルの名前を持つことができます。

43 - 3 + 2
// res7: Int = 42

43.-(3).+(2)
// res8: Int = 42

（Scala 2.10 以前においては、43. を Double として解釈されることを防ぐために、(43).-(3).+(2) と書く必要があるので注意してください。）

シンボルの名前を持つか、英数字の名前を持つかにかかわらず、1つの引数を受け取るどんなメソッドでも中置演算子記法 (infix operator notation) を使用できます。

"the quick brown fox" split " "
// res: Array[String] = Array(the, quick, brown, fox)

中置記法は、いくつかの文法的略記法のひとつで、冗長なメソッド呼び出しの代わりに、簡潔な演算子式を書くことを可能にします。前置 (prefix)・後置 (postfix)・右結合 (right-associative)・代入演算子 (assignment-style) という記法もありますが、中置記法に比べると一般的ではありません。

中置演算子の結合は何の優先順位規則を支持すべきか？という質問はそれ自身をもたらします。Scala は、数学や論理の直観的知識にならい、メソッド名として使用する識別子から得られる優先順位規則一式を使用します。

2 * 3 + 4 * 5
// res11: Int = 26

(2 * 3) + (4 * 5)
// res12: Int = 26

2 * (3 + 4) * 5
// res13: Int = 70

2.2.4 覚えておいてほしいこと

Scala のすべての値はオブジェクトです。それらのメソッド呼び出しによってオブジェクトを作用させます。Java を背景知識としているのであれば、Int や他の任意のプリミティブ値のメソッドを呼び出せることに注意してください。

メソッド呼び出しのための文法は、

anExpression.methodName(parameter, ...)

か

anExpression methodName parameter

です。

Scala は非常に少ない演算子を持ち、ほとんどすべてはメソッド呼び出しです。中置演算子記法のような文法規則をコードを簡潔かつ読みやすくするために使用しますが、標準のメソッド記法の方がわかりやすい場合はいつでもそれに戻すことができます。

のちほど見ていくように、式を伴うプログラミングにおける Scala の焦点は、Java で実現するよりさらに短いコードで書くことを可能にすることです。また、値と型を使用する非常に直観的な方法で、コードについての判断を可能にします。

2.2.5 演習

2.2.5.1 演算子スタイル

演算子スタイルに書き直してください。

"foo".take(1)
// res14: String = f

"foo" take 1
// res15: String = f

メソッド呼び出しスタイルに書き直してください。

1 + 2 + 3
// res16: Int = 6

1.+(2).+(3)
// res17: Int = 6

2.2.5.2 置換

下記の2つの式の間にある違いは何ですか？類似点は何ですか？

1 + 2 + 3

6

2.3 リテラルオブジェクト

すでに Scala の基本型のいくつかを取り上げました。本節では、Scala におけるすべてのリテラル式を扱うことによって、その知識に磨きをかける予定です。リテラル式は「それ自身」が象徴する固定値を表現します。下記はひとつの例です。

42
// res0: Int = 42

この REPL での相互作用は、リテラル 42 が Int 42 に評価されることを示しています。

リテラルとそれが評価された値を混同してはいけません。リテラル式はプログラムを実行する前のプログラムテキストにおける表現で、値はプログラムを実行した後のコンピューターのメモリにおける表現です。

これまでにプログラミングの経験、とくに Java の経験があれば、Scala におけるリテラルに見覚えがあるはずです。

2.3.1 数値

数値は Java にある同じ型を共有しており、32ビット整数の Int、64ビット浮動小数点数の Double、32ビット浮動小数点数の Float、そして64ビット整数の Long があります。

42
// res1: Int = 42

42.0
// res2: Double = 42.0

42.0f
// res3: Float = 42.0

42L
// res4: Long = 42

Scala は16ビット整数の Short と8ビットの Byte を持ちますが、それらを生成するためのリテラル文法はありません。その代わりに、toShort や toByte と呼ばれるメソッドを使用することで生成できます。

2.3.2 真偽値

真偽値は Java とちょうど同じで、true か false です。

true
// res5: Boolean = true

false
// res6: Boolean = false

2.3.3 文字値

Chars は16ビット Unicode 値で、シングルクォートで囲まれた単一の文字として書かれます。

'a'
// res7: Char = a

2.3.4 文字列値

文字列値はちょうど Java の文字列で、同じ方法で書かれます。

"this is a string"
// res8: String = this is a string

"the\nusual\tescape characters apply"
// res9: String =
// the
// usual    escape characters apply

2.3.5 Null 値

Null 値は Java と同じであるにもかかわらず、ほとんど頻繁には使用されません。また、Scala の null は独自の Null 型を持ちます。

null
// res10: Null = null

2.3.6 Unit 値

Scala で () と書かれる Unit 値は、Java の void に相当します。Unit 値は、println を使用して標準出力に印字するような、何の面白みもない値に評価される式の結果です。コンソールは Unit 値を印字しませんが、式の型を尋ねることで、実際に何らかの式の結果であることがわかります。

()

:type ()
// Unit

println("something")
// something

:type println("something")
// Unit

Unit 値は Scala において重要な概念です。Scala の文法構造の多くは、型と値を持つ式です。有用な値を得られない式のためのプレイスホルダーが必要で、Unit 値はまさにそれを提供してくれます。

2.3.7 覚えておいてほしいこと

本節では、基本的なデータ型を評価するリテラル式を見てきました。これらの基本型は、等価なものがない Unit を除いて、ほとんど Java と同じです。

すべてのリテラル式は型を持ち、値に評価されることに注意してください。これは、より複雑な Scala の式にも当てはまります。

次節では、独自のオブジェクトリテラルを定義する方法を学びます。

2.3.8 演習

2.3.8.1 文字通りただのリテラル

下記の Scala リテラルの値と型は何ですか？

42

true

123L

42.0

2.3.8.2 引用と誤引用

下記のリテラルの違いは何ですか？それぞれの型と値は？

'a'

"a"

2.3.8.3 副作用についての余談

下記の式の違いは何ですか？それぞれの型と値は？

"Hello world!"

println("Hello world!")

2.3.8.4 失敗から学ぶ

下記のリテラルの型と値は何ですか？REPL や Scala ワークシートに書いてみて、何が起こるか見てみましょう！

'Hello world!'

2.4 オブジェクトリテラル

ここまでは、Int や String のような組み込み型のオブジェクトを作成し、それらを式に組み合わせる方法を見てきました。本節では、オブジェクトリテラル (object literals) を使用して独自デザインのオブジェクトを作成する方法を見ていきます。

オブジェクトリテラルを書くとき、式とは別のプログラムの一種である宣言 (declaration) を使います。宣言は値を評価しません。その代わりに名前と値を関連付けます。この名前は他のコードで値を参照するために使用できます。

下記のように空のオブジェクトを宣言できます。

object Test {}

これは値に評価されず式ではありません。むしろ、名前 Test を空のオブジェクト値に結び付けます。

一度 Test という名前に結び付ければ式の中で使用することができ、それは宣言したオブジェクトに評価されます。もっとも単純な式はそれ自身の名前だけで、それ自体が値として評価されます。

Test
// res0: Test.type = Test$@557b7f7d

この式は 123 や "abc" のようなリテラルを書くことと同じです。オブジェクトの型は Test.type として報告されることに注意してください。これは、これまで見てきた型とは異なり、オブジェクトのためだけに作成された新しい型で、シングルトン型 (singleton type) と呼ばれます。この型における他の値を作成することはできません。

空のオブジェクトはあまり便利ではありません。オブジェクト宣言の本体である中括弧の間には式を入れることができます。しかし、メソッドやフィールド、さらなるオブジェクトを宣言するような宣言を入れるのが一般的です。

object name {
  declarationOrExpression ...
}

それではメソッドとフィールドをどのように宣言するか見ていきましょう。

2.4.1 メソッド

メソッドによってオブジェクトを作用させるので、メソッドを伴うオブジェクトを生成してみましょう。

object Test2 {
  def name: String = "Probably the best object ever"
}

ここでは name と呼ばれるメソッドを生成しました。これをいつもの方法で呼び出すことができます。

Test2.name
// res1: String = Probably the best object ever

下記はより複雑なメソッドを伴うオブジェクトです。

object Test3 {
  def hello(name: String) =
    "Hello " + name
}

Test3.hello("Noel")
// res2: String = Hello Noel

def name(parameter: type, ...): resultType =
  bodyExpression

def name: resultType =
  bodyExpression

2.4.2 フィールド

オブジェクトはフィールド (field) と呼ばれる他のオブジェクトを含めることもできます。def によく似た val や var というキーワードを使用して導入します。

object Test4 {
  val name = "Noel"
  def hello(other: String): String =
    name + " says hi to " + other
}

Test4.hello("Dave")
// res3: String = Noel says hi to Dave

val name: type = valueExpression

var name: type = valueExpression

val を使用することで不変 (immutable) フィールドを定義でき、これは名前に束縛された値の変更ができないことを意味します。var は可変 (mutable) フィールドで、束縛された値の変更ができます。

常に var より val を選びましょう。 置換を維持するため、Scala プログラマーは可能な限り不変フィールドを使用することを選びます。アプリケーションコードで時折可変フィールドを生成することは間違いありませんが、本書の大部分では var を使用しないようにしており、普段の Scala プログラミングにおいてもそれに倣いましょう。

2.4.3 メソッド対フィールド

同じ動作をするように見える引数のないメソッドを持つことができるにも関わらず、なぜフィールドが必要なのか不思議に思うかもしれません。その違いはわずかで、フィールドは値に名前を与えますが、一方のメソッドは値を算出する計算に名前を与えます。

その違いを明らかにするオブジェクトがこちらです。

object Test7 {
   val simpleField = {
     println("Evaluating simpleField")
     42
   }
   def noParameterMethod = {
     println("Evaluating noParameterMethod")
     42
   }
}

ここでは、コンソールに何かを印字するために println 式を、式をグループにするためにブロック式（{ と } によって囲まれた式）を使用しています。なお、ブロック式については、次節でより詳しく見ていきます。

オブジェクトを定義したとコンソールに表示されているのに、いずれの println 文も実行されていないことに注意してください。これは遅延読み込み (lazy loading) と呼ばれる Scala と Java の特性によるものです。

オブジェクトやクラス（後述）は、他のコードによって参照されるまで読み込まれません。これが、単純な "Hello world!" アプリを実行するために、Scala が標準ライブラリ全体をメモリに読み込むことを防いでいます。

式の中で Test7 を参照することで、Scala にオブジェクトの本体を強制的に評価させてみましょう。

Test7
// Evaluating simpleField
// res4: Test7.type = Test7$@2149aa05

オブジェクトが最初に読み込まれるとき、Scala はその定義を実行し、各フィールドの値を計算します。その結果、コードの副作用として "Evaluating simpleField" が印字されます。

フィールドにおける本体の式は一度だけ実行されます。 その後、オブジェクトにその最終的な値が格納されます。下記で println 出力が欠けていることからわかるように、その式は二度と評価されることはありません。

Test7.simpleField
// res5: Int = 42

Test7.simpleField
// res6: Int = 42

一方、下記で println 出力が繰り返されていることからわかるように、メソッドの本体はメソッドを呼び出すたびに評価されます。

Test7.noParameterMethod
// Evaluating noParameterMethod
// res7: Int = 42

Test7.noParameterMethod
// Evaluating noParameterMethod
// res8: Int = 42

2.4.4 覚えておいてほしいこと

本節では、独自のオブジェクトを作成し、メソッドとフィールドを与え、式の中で参照しました。

文法としてオブジェクトの宣言、

object name {
  declarationOrExpression ...
}

メソッドの宣言、

def name(parameter: type, ...): resultType = bodyExpression

そしてフィールドの宣言、

val name = valueExpression
var name = valueExpression

を見てきました。これらすべては宣言で、名前と値を束縛します。宣言は式とは異なります。宣言は値を評価しませんし型も持ちません。

また、メソッドとフィールドの違いを見てきました。フィールドはオブジェクトの中に格納された値を参照し、一方のメソッドは値を算出する計算を参照します。

2.4.5 演習

2.4.5.1 キャット・オ・マティック

下記の表は、3匹の猫の名前 (name)・色 (colour)・好きなエサ (food) を示しています。それぞれの猫についてのオブジェクトを定義してください。（経験豊富なプログラマーの方へ：クラスについてはまだ説明していません。）

object Oswald {
  val colour: String = "Black"
  val food: String = "Milk"
}

object Henderson {
  val colour: String = "Ginger"
  val food: String = "Chips"
}

object Quentin {
  val colour: String = "Tabby and white"
  val food: String = "Curry"
}

2.4.5.2 スクウェア・ダンス！

calc と呼ばれるオブジェクトを定義します。それは、square という Double を引数として受け取る、あなたが予想するとおり入力を2乗 (square) するメソッドを伴います。そして、計算の一部として square メソッドの呼び出し を含む cube と呼ばれる、入力を3乗 (cube) するメソッドを追加してください。

object calc {
  def square(x: Double) = x * x
  def cube(x: Double) = x * square(x)
}

2.4.5.3 精密なスクウェア・ダンス！

前の演習から calc をコピー＆ペーストして、Int と同様に Double でも動作するよう一般化された calc2 を作成してください。Java の経験を持っていれば、これはかなり簡単にできるはずです。そうでなければ、下記の解答を読んでください。

object calc2 {
  def square(value: Double) = value * value
  def cube(value: Double) = value * square(value)

  def square(value: Int) = value * value
  def cube(value: Int) = value * square(value)
}

calc2.square(1.0) // `square` の `Double` 版を呼び出す
// res11: Double = 1.0

calc2.square(1)   // `square` の `Int` 版を呼び出す
// res12: Int = 1

val x: Int = calc.square(2) // コンパイルエラー
// <console>:13: error: type mismatch;
//  found   : Double
//  required: Int
//        val x: Int = calc.square(2) // コンパイルエラー
//                                ^

val x: Int = calc.square(2).toInt // toInt は切り捨て
// x: Int = 4

2.4.5.4 評価の順番

コンソールで入力したとき、下記プログラムの出力は何で、最終的な式の型と値は何になるでしょうか？各フィールドやメソッドの型や依存関係、評価の振る舞いをよく考えてみてください。

object argh {
  def a = {
    println("a")
    1
  }

  val b = {
    println("b")
    a + 2
  }

  def c = {
    println("c")
    a
    b + "c"
  }
}

argh.c + argh.b + argh.a

argh.c + argh.b + argh.a
// b
// a
// c
// a
// a
// res13: String = 3c31

- プログラムの最後にあるメインの合計を計算するには、
  - `argh` を読み込み、
    - `argh` のすべてのフィールドを計算するので、
      - `b` を計算すると、
        - `"b"` を印字し、
        - `a + 2` を評価するので、
          - `a` を呼び出し、
            - `"a"` を印字し、
            - `1` を返却し、
          - `1 + 2` を返却し、
        - `b` に値 `3` を格納し、
  - `argh.c` を呼び出し、
    - `"c"` を印字し、
    - `a` を評価し、
      - `"a"` を印字し、
      - `1` を返却するのですが、それは破棄され、
    - `b + "c"` を評価し、
      - `b` から値 `3` を取得し、
        - 値 `"c"` を取得し、
        - `+` を評価し、それが実際のところ文字列の連結を参照していると判断し、
          `3` を `"3"` に変換し、
        - 文字列 `"3c"` を返却し、
  - `argh.b` を呼び出し,
    - `b` から値 `3` を取得し、
  - 最初の `+` を評価し、それが実際のところ文字列の連結を参照していると判断し、
    `"3c3"` を生成し、
  - `argh.a` を呼び出し、
    - `"a"` を印字し、
    - `1` を返却し、
  - 最初の `+` を評価し、それが実際のところ文字列の連結を参照していると判断し、
    `"3c31"` を生成する

2.4.5.5 やぁ、人間

person というオブジェクトを定義します。それは、firstName と lastName というフィールドを含みます。alien という2番目のオブジェクトを定義します。それは、引数として person を受け取り、その firstName を使用して挨拶する greet というメソッドを含みます。

greet メソッドの型は何でしょうか？このメソッドを使用して他のオブジェクトに挨拶することはできますか？

object person {
  val firstName = "Dave"
  val lastName = "Gurnell"
}

object alien {
  def greet(p: person.type) =
    "Greetings, " + p.firstName + " " + p.lastName
}

alien.greet(person)
// res15: String = Greetings, Dave Gurnell

2.4.5.6 メソッドの真価

メソッドは値ですか？式ですか？なぜそうなるのでしょうか？

object calculator {
  def square(x: Int) = x * x
}

val someField = calculator.square
// <console>:15: error: missing argument list for method square in object calculator
// Unapplied methods are only converted to functions when a function type is expected.
// You can make this conversion explicit by writing `square _` or `square(_)` instead of `square`.
//        val someField = calculator.square
//                                   ^

val someField = calculator.square(2)
// someField: Int = 4

object clock {
  def time = System.currentTimeMillis
}

val now = clock.time
// now: Long = 1591093416177

val aBitLaterThanNow = clock.time
// aBitLaterThanNow: Long = 1591093416354

2.5 メソッドの書き方

前節では、メソッドの文法について見てきました。本書の主な目的のひとつは、文法を超えて、Scala プログラムを構築するための体系的な方法を提供することです。本節はそのような問題を扱う最初の節です。本節では、体系的にメソッドを構築する方法を見ていきます。Scala の経験を積んでいくうちに、この方法のいくつかの段階を省略することができますが、本書の中ではこの方法に従うことを強く推奨します。

アドバイスを具体的にするために、前節の演習を例として使用していきましょう。

calc と呼ばれるオブジェクトを定義します。それは、square という Double を引数として受け取る、あなたが予想するとおり入力を2乗 (square) するメソッドを伴います。そして、計算の一部として square メソッドの呼び出しを含む cube と呼ばれる、入力を3乗 (cube) するメソッドを追加してください。

2.5.1 入力と出力を特定する

最初の段階は、入力となる引数がもしあれば、その型とメソッドの結果型を特定することです。

多くの場合、演習では型を教えてくれるので、説明文からそのまま読み取ることができます。上の例で、入力型は Double になっています。結果型もまた Double になることが推論できます。

2.5.2 テストケースを準備する

型だけでは物語のすべてを語れません。Double から Double への関数はたくさんありますが、2乗を実行しているものは少数です。そのため、メソッドの期待される振る舞いを例証するいくつかのテストケースを準備しましょう。

外部依存を避けたいので、本書ではテストライブラリを使用しないことにします。Scala が提供する assert 関数を使用することで手軽なテストライブラリを実装できます。square の例については、下記のようなテストケースが考えられます。

assert(square(2.0) == 4.0)
assert(square(3.0) == 9.0)
assert(square(-2.0) == 4.0)

2.5.3 宣言を書く

型とテストケースが準備できたので、メソッド宣言を書くことができます。その本体はまだ書けないので、その場所に Scala の便利な機能である ??? を使用しておきます。

def square(in: Double): Double =
  ???

この段階は、前の段階で収集した情報から機械的に与えられるべきです。

2.5.4 コードを実行する

コードを実行し、それがコンパイルされていること（つまり、タイプミスをしていないこと）と、また、テストが失敗すること（つまり、何らかのテストが実行されていること）を確認してください。なお、メソッド宣言の後にテストを配置する必要があるかもしれません。

2.5.5 本体を書く

メソッドの本体を書く準備が整いました。本書を通じて、いくつかのテクニックを修得していきます。現時点では、2つのテクニックを見ていきましょう。

2.5.5.1 結果型を考える

最初のテクニックは、結果型を見ることです。この場合は Double です。どうやって Double の値を生成するのでしょうか？リテラルを書くこともできますが、この場合は明らかに正しくありません。Double を生成する他の方法は、何らかのオブジェクトのメソッドを呼び出すことで、それは次のテクニックがもたらします。

2.5.5.2 入力型を考える

次のテクニックは、メソッドの入力引数の型を見ることです。この場合は Double です。Double を生成する必要があることは確立していますが、入力から Double を生成するためにはどのようなメソッドを呼び出せばいいのでしょうか？そのようなメソッドはたくさんありますが、ここで呼び出すべき正しいメソッドとして * を選択するためにはドメイン知識を活用しなければなりません。

完全なメソッドは下記のように書くことができます。

def square(in: Double): Double =
  in * in

2.5.6 コードを再実行する

最後に、コードを再実行して、テストがすべて通過することを確認します。

これはとても単純な例でしたが、今のプロセスを実践することで、今後遭遇するであろうより複雑な例にうまく対応できるようになります。

def name(parameter: type, ...): resultType =
 ???

2.6 複合式

これで Scala の基本的な入門編はほぼ終了しました。本節では、より複雑なプログラムで必要になるであろう、条件式 (conditional) と ブロック (block) という2種類の特別な式について見ていきます。

2.6.1 条件式

条件式は、ある条件にもとづいて評価する式を選択することを可能にします。例えば、2つの数値のうちどちらが小さいかにもとづいて文字列を選択することができます。

if(1 < 2) "Yes" else "No"
// res0: String = Yes

選択されない式は評価されません。これは、副作用を伴う式を使用すると明らかです。

if(1 < 2) println("Yes") else println("No")
// Yes

No がコンソールに出力されないので、println("No") という式は評価されていないことがわかります。

if(condition)
  trueExpression
else
  falseExpression

2.6.2 ブロック

ブロックは、計算をまとめて並べることができる式のことです。それは、セミコロンもしくは改行によって区切られた部分式を含む中括弧のペアとして書かれます。

{ 1; 2; 3 }
// <console>:13: warning: a pure expression does nothing in statement position; you may be omitting necessary parentheses
//        { 1; 2; 3 }
//          ^
// <console>:13: warning: a pure expression does nothing in statement position; you may be omitting necessary parentheses
//        { 1; 2; 3 }
//             ^
// error: No warnings can be incurred under -Xfatal-warnings.

ご覧のように、このコードを実行すると、コンソールはいくつかの警告を発生させ、Int 値 3 を返します。

ブロックは、中括弧によって囲まれた一連の式や宣言のことです。ブロックもまた式であり、各部分式を順番に実行し、最後の式の値を返します。

1 と 2 の値を捨ててしまうなら、なぜそれらを実行するのでしょうか？これはいい質問で、上記で Scala コンパイラーが警告を発生させた理由にもなります。

ブロックを使用するひとつの理由は、最終的な値を計算する前に副作用を生成するコードを使用したいからです。

{
  println("This is a side-effect")
  println("This is a side-effect as well")
  3
}
// This is a side-effect
// This is a side-effect as well
// res3: Int = 3

また、下記のように中間結果に名前をつけたいときにブロックを使用することもできます。

def name: String = {
  val title = "Professor"
  val name = "Funkenstein"
  title + " " + name
}

name
// res4: String = Professor Funkenstein

{
   declarationOrExpression ...
   expression
}

2.6.3 覚えておいてほしいこと

条件式は Boolean の条件にもとづいて評価する式を選択することを可能にします。その文法は下記のとおりです。

if(condition)
  trueExpression
else
  falseExpression

式である条件式は、型を持ち、オブジェクトに評価されます。

ブロックは、式や宣言を順番に並べることを可能にします。それは、副作用を伴う式を順番に並べたり、計算における中間結果に名前をつけたりしたいときによく使用されます。その文法は下記のとおりです。

{
   declarationOrExpression ...
   expression
}

ブロックの型と値は、ブロックにおける最後の式になります。

2.6.4 演習

2.6.4.1 模範的なライバル関係

下記の条件式における型と値は何ですか？

if(1 > 2) "alien" else "predator"

if(1 > 2) "alien" else "predator"
// res6: String = predator

2.6.4.2 あまり知られていないライバル関係

この条件式はどうでしょうか？

if(1 > 2) "alien" else 2001

if(1 > 2) "alien" else 2001
// res8: Any = 2001

2.6.4.3 else のない if

この条件式はどうでしょうか？

if(false) "hello"

if(false) "hello"
// res10: Any = ()

2.7 まとめ

本章では、Scala の基礎をとても簡単に紹介しました。

• 値に評価される式
• 値に名前を与える宣言

たくさんのオブジェクトについてリテラルで書く方法や、既存のオブジェクトから新しいオブジェクトを生成するためにメソッド呼び出しや複合式を使用する方法を見てきました。

また、独自のオブジェクトを宣言し、メソッドやフィールドを構築しました。

次章では、新しい種類の宣言であるクラスが、どのようにオブジェクトを生成するためのテンプレートを提供するのかを見ていきます。クラスは、コードを再利用したり、共通の型で類似のオブジェクトを統一したりすることを可能にします。

3 オブジェクトとクラス

前章では、オブジェクトを作成し、メソッド呼び出しを通じてオブジェクトを作用させる方法を見ました。本章では、クラス (class) を使用してオブジェクトを抽象化する方法を見ていきます。クラスはオブジェクトを構築するためのテンプレートです。クラスが与えられれば、同じ型を持ち、共通のプロパティを持つ多くのオブジェクトをつくることができます。

3.1 クラス

クラスは、似たようなメソッドやフィールドを持つオブジェクトを生成するためのテンプレートです。Scala では、クラスもまた型を定義し、クラスから生成されたすべてのオブジェクトは同じ型を共有します。これによって、前章の演習「やぁ、人間」が持つ問題を克服することができます。

3.1.1 クラスを定義する

これは、シンプルな Person クラスの宣言です。

class Person {
  val firstName = "Noel"
  val lastName = "Welsh"
  def name = firstName + " " + lastName
}

オブジェクト宣言のように、クラス宣言は名前（この場合 Person）を束縛し、また式ではありません。しかしながら、オブジェクト名と違って、式の中でクラス名を使用することはできません。クラスは値ではなく、クラスは異なる名前空間 (namespace) に住んでいます。

Person
// <console>:13: error: not found: value Person
//        Person
//        ^

new 演算子を使用して、新しい Person オブジェクトを生成できます。オブジェクトは値なので、通常の方法でそれらのメソッドやフィールドにアクセスできます。

val noel = new Person
// noel: Person = Person@15bfe8fd

noel.firstName
// res1: String = Noel

オブジェクトの型が Person であることに注意してください。印字された値には、@xxxxxxxx という形式のコードが含まれており、そのオブジェクトを特定する一意の識別子です。new を呼び出すたびに、同じ型の別オブジェクトが生成されます。

noel
// res2: Person = Person@15bfe8fd

val newNoel = new Person
// newNoel: Person = Person@60cea738

val anotherNewNoel = new Person
// anotherNewNoel: Person = Person@22fe5689

これは、引数として任意の Person を受け取るメソッドを書けることを意味します。

object alien {
  def greet(p: Person) =
    "Greetings, " + p.firstName + " " + p.lastName
}

alien.greet(noel)
// res3: String = Greetings, Noel Welsh

alien.greet(newNoel)
// res4: String = Greetings, Noel Welsh

3.1.2 コンストラクター

現状、Person クラスは全然役に立ちません。新しいオブジェクトを好きなだけ生成することができますが、すべて同じ firstName と lastName を持つためです。それでは、それぞれの人に異なる名前を与えるにはどうすればいいのでしょうか？

その解決策は、コンストラクター (constructor) を導入することで、それは新しいオブジェクトを生成するときに引数を渡すことを可能にします。

class Person(first: String, last: String) {
  val firstName = first
  val lastName = last
  def name = firstName + " " + lastName
}

val dave = new Person("Dave", "Gurnell")
// dave: Person = Person@258c10ba

dave.name
// res5: String = Dave Gurnell

コンストラクター引数 first と last はクラスの本体でのみ使用できます。オブジェクトの外側からデータにアクセスするには、val や def を使用してフィールドやメソッドを宣言しなければなりません。

コンストラクター引数とフィールドはしばしば冗長です。幸運なことに、Scala は両方を一度に宣言する便利な略記法を提供してくれています。コンストラクター引数の前に val キーワードをつけることで、Scala はそれらのフィールドを自動的に定義してくれるようになります。

class Person(val firstName: String, val lastName: String) {
  def name = firstName + " " + lastName
}

new Person("Dave", "Gurnell").firstName
// res6: String = Dave

val フィールドは不変 (immutable) で、一度初期化された後にそれらの値を変更することはできません。Scala は可変 (mutable) フィールドを定義するために var キーワードも提供しています。

Scala プログラマーは、不変かつ副作用のないコードを書くことを好む傾向があるので、置換モデルを使用してそれらを導出することができます。本書では、もっぱら不変な val フィールドに焦点を当てていきます。

class Name(parameter: type, ...) {
  declarationOrExpression ...
}

class Name(val parameter: type, ...) {
  declarationOrExpression ...
}

3.1.3 デフォルト引数とキーワード引数

Scala のすべてのメソッドとコンストラクターは、キーワード引数 (keyword parameter) とデフォルト引数値 (default parameter value) に対応しています。

メソッドやコンストラクターを呼び出すときに、任意の順番で引数を指定するためのキーワードとして引数名を使用することができます。

new Person(lastName = "Last", firstName = "First")
// res7: Person = Person@5cce4fcc

これは、下記のように定義されたデフォルト引数値と組み合わせて使用するといっそう便利です。

def greet(firstName: String = "Some", lastName: String = "Body") =
  "Greetings, " + firstName + " " + lastName + "!"

引数がデフォルト値を持つのであれば、メソッド呼び出しでその引数を省略できます。

greet("Busy")
// res8: String = Greetings, Busy Body!

デフォルト引数値とキーワードを組み合わせることで、前の引数を省略し、後の引数だけに値を渡すこともできます。

greet(lastName = "Dave")
// res9: String = Greetings, Some Dave!

def greet(title: String = "Citizen", firstName: String = "Some", lastName: String = "Body") =
  "Greetings, " + title + " " + firstName + " " + lastName + "!"

greet("Busy") // これは正しくなくなりました
// res10: String = Greetings, Busy Some Body!

greet(firstName = "Busy") // これは正しいままです
// res11: String = Greetings, Citizen Busy Body!

3.1.4 Scala の型階層

プリミティブ型とオブジェクト型を区別する Java とは異なり、Scala ではすべてがオブジェクトです。その結果、Int や Boolean のような「プリミティブ」値の型は、クラスやトレイトと同じ型階層の一部を構成しています。

Scala は Any と呼ばれる最上位の基底型を持ち、その下に AnyVal と AnyRef という2つの型があります。AnyVal はすべての値型の基底型で、AnyRef はすべての参照型やクラスの基底型です。Scala や Java におけるすべてのクラスは AnyRef の派生型です⁴。

それらの型のいくつかは、単純に Java に存在する型の Scala における別名で、Int は int、Boolean は boolean、AnyRef は java.lang.Object です。

階層の最下位 (bottom) に2つの特別な型があります。Nothing は throw 式の型で、Null は null 値の型です。それらの特別な型は、他のすべての型の派生型で、コードにおける他の型を健全に保ちながらも、throw や null に型を割り当てることを補助します。下記のコードはこのことを説明しています。

def badness = throw new Exception("Error")
// badness: Nothing

def otherbadness = null
// otherbadness: Null

val bar = if(true) 123 else badness
// bar: Int = 123

val baz = if(false) "it worked" else otherbadness
// baz: String = null

badness と otherbadness の型はそれぞれ Nothing と Null であるにも関わらず、bar と baz の型は実用的なままです。なぜならば、Int は Int と Nothing の最小共通基底型で、String は String と Null の最小共通基底型であるからです。

3.1.5 覚えておいてほしいこと

本節では、同じ型を持つ様々なオブジェクトの生成を可能にするクラスを定義する方法を学びました。このように、クラスを使うことで、似たような性質を持つオブジェクトを横断的に抽象化することができます。

クラスにおいてもオブジェクトの性質は、フィールドとメソッドの形をとります。フィールドはオブジェクトに格納される事前に計算された値で、メソッドは呼び出すことができる計算です。

クラスを宣言するための文法は、

class Name(parameter: type, ...) {
  declarationOrExpression ...
}

です。

new キーワードを使用し、コンストラクターを呼び出すことによって、クラスからオブジェクトを生成します。

また、キーワード引数とデフォルト引数についても学びました。

最後に、Scala の型階層について、Java の型階層との重複や、特殊な型である Any や AnyRef、AnyVal、Nothing、Null、Unit を含むこと、そして Java のクラスと Scala のクラスは、どちらも型階層の同じサブツリーを占有するという事実を学びました。

3.1.6 演習

今ではクラスで楽しく遊ぶために十分な機構を手に入れました。

3.1.6.1 猫、再び

以前の演習に登場した猫を思い出しましょう。

Cat クラスを定義し、上の表の各猫についてオブジェクトを生成してください。

class Cat(val colour: String, val food: String)

val oswald = new Cat("Black", "Milk")
val henderson = new Cat("Ginger", "Chips")
val quentin = new Cat("Tabby and white", "Curry")

3.1.6.2 猫、ぶらぶらする

willServe メソッドを伴う ChipShop オブジェクトを定義してください。このメソッドは Cat を受け取り、猫の好きなエサがカリカリ (chips) であれば true を返し、そうでなければ false を返します。

object ChipShop {
  def willServe(cat: Cat): Boolean =
    if(cat.food == "Chips")
      true
    else
      false
}

3.1.6.3 監督デビュー

下記のフィールドとメソッドを伴う、Director と Film の2つのクラスを書いてください。

• Director に含まれる：
  • String 型の firstName フィールド
  • String 型の lastName フィールド
  • Int 型の yearOfBirth フィールド
  • 無引数で、フルネームを返す name メソッド
• Film に含まれる：
  • String 型の name フィールド
  • Int 型の yearOfRelease フィールド
  • Double 型の imdbRating フィールド
  • Director 型の director フィールド
  • 公開時における監督の年齢を返す directorsAge メソッド
  • 引数として Director を受け取り、Boolean を返す isDirectedBy メソッド

下記のデモデータをコードにコピー＆ペーストし、そのコードを変更せずに動作するようコンストラクターを調整してください。

val eastwood          = new Director("Clint", "Eastwood", 1930)
val mcTiernan         = new Director("John", "McTiernan", 1951)
val nolan             = new Director("Christopher", "Nolan", 1970)
val someBody          = new Director("Just", "Some Body", 1990)

val memento           = new Film("Memento", 2000, 8.5, nolan)
val darkKnight        = new Film("Dark Knight", 2008, 9.0, nolan)
val inception         = new Film("Inception", 2010, 8.8, nolan)

val highPlainsDrifter = new Film("High Plains Drifter", 1973, 7.7, eastwood)
val outlawJoseyWales  = new Film("The Outlaw Josey Wales", 1976, 7.9, eastwood)
val unforgiven        = new Film("Unforgiven", 1992, 8.3, eastwood)
val granTorino        = new Film("Gran Torino", 2008, 8.2, eastwood)
val invictus          = new Film("Invictus", 2009, 7.4, eastwood)

val predator          = new Film("Predator", 1987, 7.9, mcTiernan)
val dieHard           = new Film("Die Hard", 1988, 8.3, mcTiernan)
val huntForRedOctober = new Film("The Hunt for Red October", 1990, 7.6, mcTiernan)
val thomasCrownAffair = new Film("The Thomas Crown Affair", 1999, 6.8, mcTiernan)

eastwood.yearOfBirth
// res16: Int = 1930

dieHard.director.name
// res17: String = John McTiernan

invictus.isDirectedBy(nolan)
// res18: Boolean = false

さらに、copy と呼ばれる Film のメソッドを実装します。このメソッドは、コンストラクターと同じ引数を受け取り、映画の新しいコピーを生成します。各引数にデフォルト値を与えて、映画の値の一部を変更してコピーできるようにします。

highPlainsDrifter.copy(name = "L'homme des hautes plaines")
// res19: Film = Film(L'homme des hautes plaines,1973,7.7,Director(Clint,Eastwood,1930))

thomasCrownAffair.copy(yearOfRelease = 1968,
  director = new Director("Norman", "Jewison", 1926))
// res20: Film = Film(The Thomas Crown Affair,1968,6.8,Director(Norman,Jewison,1926))

inception.copy().copy().copy()
// res21: Film = Film(Inception,2010,8.8,Director(Christopher,Nolan,1970))

class Director(
  val firstName: String,
  val lastName: String,
  val yearOfBirth: Int) {

  def name: String =
    s"$firstName $lastName"

  def copy(
    firstName: String = this.firstName,
    lastName: String = this.lastName,
    yearOfBirth: Int = this.yearOfBirth): Director =
    new Director(firstName, lastName, yearOfBirth)
}

class Film(
  val name: String,
  val yearOfRelease: Int,
  val imdbRating: Double,
  val director: Director) {

  def directorsAge =
    yearOfRelease - director.yearOfBirth

  def isDirectedBy(director: Director) =
    this.director == director

  def copy(
    name: String = this.name,
    yearOfRelease: Int = this.yearOfRelease,
    imdbRating: Double = this.imdbRating,
    director: Director = this.director): Film =
    new Film(name, yearOfRelease, imdbRating, director)
}

3.1.6.4 シンプル・カウンター

Counter クラスを実装してください。コンストラクターは Int を受け取るようにしてください。カウンターを増加させる inc メソッドとカウンターを減少させる dec メソッドを、それぞれ新しい Counter を返すように実装してください。こちらが利用例です。

new Counter(10).inc.dec.inc.inc.count
// res23: Int = 12

class Counter(val count: Int) {
  def dec = new Counter(count - 1)
  def inc = new Counter(count + 1)
}

3.1.6.5 高速カウント

前の演習に登場した Counter を拡張し、ユーザーが inc と dec に Int 引数を任意に渡せるようにしてください。引数が省略されたときは、1 をデフォルトにしてください。

class Counter(val count: Int) {
  def dec(amount: Int = 1) = new Counter(count - amount)
  def inc(amount: Int = 1) = new Counter(count + amount)
}

new Counter(10).inc
// <console>:14: error: missing argument list for method inc in class Counter
// Unapplied methods are only converted to functions when a function type is expected.
// You can make this conversion explicit by writing `inc _` or `inc(_)` instead of `inc`.
//        new Counter(10).inc
//                        ^

class Counter(val count: Int) {
  def dec: Counter = dec()
  def inc: Counter = inc()
  def dec(amount: Int = 1): Counter = new Counter(count - amount)
  def inc(amount: Int = 1): Counter = new Counter(count + amount)
}

new Counter(10).inc.inc(10).count
// res25: Int = 21

3.1.6.6 追加カウント

こちらは Adder と呼ばれるシンプルなクラスです。

class Adder(amount: Int) {
  def add(in: Int) = in + amount
}

Counter を拡張し、adjust と呼ばれるメソッドを追加してください。このメソッドは Adder を受け入れ、count に Adder を適用した結果を伴う新しい Counter を返します。

class Counter(val count: Int) {
  def dec = new Counter(count - 1)
  def inc = new Counter(count + 1)
  def adjust(adder: Adder) =
    new Counter(adder.add(count))
}

public class MyActionListener implements ActionListener {
  public void actionPerformed(ActionEvent evt) {
    // 何か計算を実行する
  }
}

3.2 関数としてのオブジェクト

前節、最後の演習で Adder と呼ばれるクラスを定義しました。

class Adder(amount: Int) {
  def add(in: Int): Int = in + amount
}

議論の中で、計算を表現するオブジェクトとしての Adder を説明しました。それは、値として渡すことのできるメソッドを得られたようなものでした。

計算のように振る舞うオブジェクトは強力な概念で、Scala にはそれを生成するための言語機能が完全に備わっています。それらのオブジェクトは関数 (function) と呼ばれ、関数型プログラミング (functional programming) の基礎を成します。

3.2.1 apply メソッド

ここでは、関数型プログラミングをサポートする Scala の一機能関数適用文法 (function application syntax) を見ていきましょう。

Scala では、慣例によって、apply と呼ばれるメソッドを持つオブジェクトを関数のように「呼び出す」ことができます。apply と名付けられたメソッドによって、呼び出し文法 foo.apply(args) が foo(args) になるという特別な略記法が与えられます。

例えば、Adder の add メソッドを apply に改名してみましょう。

class Adder(amount: Int) {
  def apply(in: Int): Int = in + amount
}

val add3 = new Adder(3)
// add3: Adder = Adder@3390766f

add3.apply(2)
// res0: Int = 5

add3(4) // add3.apply(4) の略記法
// res1: Int = 7

この簡単なトリックによって、オブジェクトは文法的に関数らしく「見える」ようになります。オブジェクトを、変数に代入したり、引数として受け渡したり、メソッドではできなかったことがたくさんできます。

3.2.2 覚えておいてほしいこと

本節では、オブジェクトを関数であるかのように「呼び出す」ための関数適用文法を見ました。

関数適用文法は、apply メソッドが定義されたどんなオブジェクトでも利用可能です。

関数適用文法によって、計算のように振る舞う第一級値（訳注：第一級関数）を持てるようになりました。メソッドと違って、オブジェクトはデータとして受け渡すことができます。これで、Scala における真の関数型プログラミングに一歩近付きました。

3.2.3 演習

3.2.3.1 関数が関数でないのはどんなとき？

次節の最後に、いくつかのコードを書く機会があります。ここで、重要な理論上の疑問について考えてみましょう。

関数適用文法は、計算を実行する真に再利用可能なオブジェクトを生成できることに、どのくらい近付いているのでしょうか？何が足りないのでしょうか？

3.3 コンパニオンオブジェクト

論理的にはクラスに所属していても、どの特定のオブジェクトからも独立しているメソッドを作成したいことがあります。そのために Java では静的メソッド (static method) を使用しますが、Scala にはシングルトンオブジェクトというもっと単純な解決策があります。

一般的な使用例は補助コンストラクターです。Scala がクラスについて複数のコンストラクターを定義できる文法を持つにも関わらず、Scala プログラマーはほとんどの場合、クラスと同じ名前を持つオブジェクトに、追加のコンストラクターとして apply メソッドを実装することを好みます。そのオブジェクトをクラスのコンパニオンオブジェクト (companion object) と呼びます。例えば、下記のようになります。

class Timestamp(val seconds: Long)

object Timestamp {
  def apply(hours: Int, minutes: Int, seconds: Int): Timestamp =
    new Timestamp(hours*60*60 + minutes*60 + seconds)
}

Timestamp(1, 1, 1).seconds
// res1: Long = 3661

前述のように、Scala は、型名 (type name) 空間と値名 (value name) 空間の2つの名前空間を持ちます。このように分離することで、衝突なくクラスとコンパニオンオブジェクトに同じ名前を付けることができます。

シングルトンオブジェクトは独自の型を伴うので、コンパニオンオブジェクトはクラスのインスタンスではないという重要なことに注意してください。

Timestamp // 型は `Timestamp.type` であり `Timestamp` ではないことに注意
// res2: Timestamp.type = Timestamp$@74d89b8f

class Name {
  ...
}

object Name {
  ...
}

3.3.1 覚えておいてほしいこと

コンパニオンオブジェクトは、機能をクラスのインスタンスに関連付けることなく、クラスに関連付ける手段を提供します。一般的に、それらは追加のコンストラクターを提供するために使用されます。

コンパニオンオブジェクトは Java の静的メソッドを代替します。それらは等価な機能を提供し、より柔軟です。

コンパニオンオブジェクトは、関連付けられたクラスと同じ名前を持ちます。 これは、値の名前空間と型の名前空間という2つの名前空間を Scala が持つため、名前の衝突を引き起こしません。

コンパニオンオブジェクトは、関連付けられたクラスと同じファイルに定義されなければいけません。 REPL 上で入力するときは :paste モードを使用して、クラスとコンパニオンオブジェクトが同じコードブロックで入力されなければいけません。

3.3.2 演習

3.3.2.1 フレンドリーな人ファクトリ

姓と名を個別にではなく、姓名全体をひとつの文字列として受け取る apply メソッドを含む、Person のコンパニオンオブジェクトを実装してください。

ヒント：下記のようにして String を Array の要素に分割できます。

val parts = "John Doe".split(" ")
// parts: Array[String] = Array(John, Doe)

parts(0)
// res3: String = John

class Person(val firstName: String, val lastName: String) {
  def name: String =
    s"$firstName $lastName"
}

object Person {
  def apply(name: String): Person = {
    val parts = name.split(" ")
    new Person(parts(0), parts(1))
  }
}

Person.apply("John Doe").firstName // 完全なメソッド呼び出し
// res5: String = John

Person("John Doe").firstName // 糖衣適用文法
// res6: String = John

3.3.2.2 業績の派生的な内容

下記のように、Director と Film のためのコンパニオンオブジェクトを記述してください。

• Director コンパニオンオブジェクトに含まれる：
  • クラスのコンストラクターと同じ引数を受け取り、新しい Director を返す apply メソッド
  • 2つの Director を受け取り、2つのうち年齢が上の方を返す older メソッド
• Film コンパニオンオブジェクトに含まれる：
  • クラスのコンストラクターと同じ引数を受け取り、新しい Film を返す apply メソッド
  • 2つの Film を受け取り、2つのうち imdbRating が高い方を返す highestRating メソッド
  • 2つの Film を受け取り、それぞれの撮影時に年齢が上の Director を返すoldestDirectorAtTheTime メソッド

class Director(
  val firstName: String,
  val lastName: String,
  val yearOfBirth: Int) {

  def name: String =
    s"$firstName $lastName"

  def copy(
    firstName: String = this.firstName,
    lastName: String = this.lastName,
    yearOfBirth: Int = this.yearOfBirth) =
    new Director(firstName, lastName, yearOfBirth)
}

object Director {
  def apply(firstName: String, lastName: String, yearOfBirth: Int): Director =
    new Director(firstName, lastName, yearOfBirth)

  def older(director1: Director, director2: Director): Director =
    if (director1.yearOfBirth < director2.yearOfBirth) director1 else director2
}

class Film(
  val name: String,
  val yearOfRelease: Int,
  val imdbRating: Double,
  val director: Director) {

  def directorsAge =
    director.yearOfBirth - yearOfRelease

  def isDirectedBy(director: Director) =
    this.director == director

  def copy(
    name: String = this.name,
    yearOfRelease: Int = this.yearOfRelease,
    imdbRating: Double = this.imdbRating,
    director: Director = this.director) =
    new Film(name, yearOfRelease, imdbRating, director)
}

object Film {
  def apply(
    name: String,
    yearOfRelease: Int,
    imdbRating: Double,
    director: Director): Film =
    new Film(name, yearOfRelease, imdbRating, director)

  def newer(film1: Film, film2: Film): Film =
    if (film1.yearOfRelease < film2.yearOfRelease) film1 else film2

  def highestRating(film1: Film, film2: Film): Double = {
    val rating1 = film1.imdbRating
    val rating2 = film2.imdbRating
    if (rating1 > rating2) rating1 else rating2
  }

  def oldestDirectorAtTheTime(film1: Film, film2: Film): Director =
    if (film1.directorsAge > film2.directorsAge) film1.director else film2.director
}

3.3.2.3 型か値か？

クラスとコンパニオンオブジェクトの名前付けによる類似は、新しい Scala 開発者の混乱を引き起こしがちです。コードのブロックを読んでいるとき、その部分がクラス（型）を示しているのか、シングルトンオブジェクト（値）を示しているのかについて知っていることが重要です。

「型か値か？」 という新しくヒットしそうなクイズを思いついたので、これから試してみましょう。単語 Film の参照しているものが型か値かをそれぞれの事例で特定してください。

val prestige: Film = bestFilmByChristopherNolan()

new Film("Last Action Hero", 1993, mcTiernan)

Film("Last Action Hero", 1993, mcTiernan)

Film.apply("Last Action Hero", 1993, mcTiernan)

Film.newer(highPlainsDrifter, thomasCrownAffair)

最後は難しいものを……

Film.type

3.4 ケースクラス

ケースクラス (case class) は、クラスやコンパニオンオブジェクト、たくさんの実用的なデフォルト機能をまとめて定義してくれる非常に便利な略記法です。それは、やっかいごとを最小限にして、軽量なデータ保持クラスを生成するための理想的な方法になります。

ケースクラスは、クラス定義にキーワード case を前置するだけで生成されます。

case class Person(firstName: String, lastName: String) {
  def name = firstName + " " + lastName
}

ケースクラスを定義するとき、いつでも Scala は自動的にクラスとコンパニオンオブジェクトを生成します。

val dave = new Person("Dave", "Gurnell") // クラスを持つ
// dave: Person = Person(Dave,Gurnell)

Person // コンパニオンオブジェクトも
// res0: Person.type = Person

さらに、クラスとコンパニオンオブジェクトには、とても便利ないくつかの機能があらかじめ用意されています。

3.4.1 ケースクラスの機能

1. 各コンストラクター引数のフィールド。コンストラクター定義に val と書く必要はありませんし、明示的に書いても悪影響はありません。

dave.firstName
// res1: String = Dave

2. デフォルト toString メソッド。それは、クラスのコンストラクターに似た実用的な表現を印字します。もう @ 記号と謎めいた16進数とはおさらばです。

dave
// res2: Person = Person(Dave,Gurnell)

3. 実用的な equals メソッドと hashCode メソッド。それらは、オブジェクトのフィールド値に基づいて動作します。

これは、List や Set、Map のようなコレクションでケースクラスを使いやすくします。また、オブジェクトを参照 ID の代わりに、それらの内容に基づいて比較できるようになります。

new Person("Noel", "Welsh").equals(new Person("Noel", "Welsh"))
// res3: Boolean = true

new Person("Noel", "Welsh") == new Person("Noel", "Welsh")
// res4: Boolean = true

4. copy メソッド。copy メソッドは、現在のオブジェクトと同じフィールド値を伴う新しいオブジェクトを生成します。

dave.copy()
// res5: Person = Person(Dave,Gurnell)

copy メソッドは、現在のオブジェクトの代わりに、クラスの新しいオブジェクトを生成して返すことに注意してください。

実のところ、copy メソッドは、それぞれのコンストラクター引数と一致する任意の引数を受け取ります。引数が指定されれば、新しいオブジェクトは、既存のオブジェクトに存在する値の代わりにその値を使用します。これは、1つ以上のフィールド値を変更してオブジェクトをコピーするときに、キーワード引数と一緒に使用するのが理想的です。

dave.copy(firstName = "Dave2")
// res6: Person = Person(Dave2,Gurnell)

dave.copy(lastName = "Gurnell2")
// res7: Person = Person(Dave,Gurnell2)

new Person("Noel", "Welsh") eq (new Person("Noel", "Welsh"))
// res8: Boolean = false

dave eq dave
// res9: Boolean = true

5. ケースクラスは java.io.Serializable と scala.Product という2つのトレイトを実装します。どちらも直接使用されることはありません。後者は、ケースクラスの名前とフィールド数を調べるためのメソッドを提供します。

3.4.2 ケースクラスコンパニオンオブジェクトの機能

コンパニオンオブジェクトは、クラスのコンストラクターと同じ引数を持つ apply メソッドを含みます。Scala プログラマーは、new を省略できる簡潔さのために、コンストラクターより apply メソッドを好む傾向があり、コンストラクターが式の中で読み易くなるようにします。

Person("Dave", "Gurnell") == Person("Noel", "Welsh")
// res10: Boolean = false

Person("Dave", "Gurnell") == Person("Dave", "Gurnell")
// res11: Boolean = true

最後に、コンパニオンオブジェクトは、パターンマッチング (pattern matching) に使用する抽出子パターン (extractor pattern) を実装するコードも含みます。本章で後ほど見ていきます。

case class Name(parameter: type, ...) {
  declarationOrExpression ...
}

3.4.3 ケースオブジェクト

最後の覚え書きです。コンストラクター引数なしでケースクラスを定義しているものをみつけたら、その代わりにケースオブジェクト (case object) を定義できます。ケースオブジェクトは、単に通常のシングルトンオブジェクトのように定義されますが、もっと意味のある toString メソッドを持ち、Product と Serializable トレイトを継承しています。

case object Citizen {
  def firstName = "John"
  def lastName  = "Doe"
  def name = firstName + " " + lastName
}

Citizen.toString
// res12: String = Citizen

3.4.4 覚えておいてほしいこと

ケースクラスは Scala データ型の真髄です。それを使って、学んで、好きになってください。

ケースクラスを宣言するための文法は、case を付与すること以外はクラスを宣言するためのものと同じです。

case class Name(parameter: type, ...) {
  declarationOrExpression ...
}

ケースクラスは、タイピングの手間を省く、たくさんの自動生成されたメソッドと機能を持ちます。関連するメソッドを実装することによって、その動作を個別にオーバーライドできます。

Scala 2.10 以前は、0〜22のフィールドを含むケースクラスしか定義できませんでした。Scala 2.11 で、任意サイズのケースクラスを定義する能力を獲得しました。

3.4.5 演習

3.4.5.1 ケースキャット

Cat が色とエサを String で持っていることを思い出してください。Cat を表現するケースクラスを定義しましょう。

case class Cat(colour: String, food: String)

3.4.5.2 ロジャー・イーバートは言う……

良くない映画は長すぎるが、悪くない映画は十分に短い。

コードについては必ずしも同じことを言えませんが、この場合、Director と Film をケースクラスに変換することによって、多くの定型文を取り除くことができます。この変換を実行し、どのコードを削除できるか試してみましょう。

case class Director(firstName: String, lastName: String, yearOfBirth: Int) {
  def name: String =
    s"$firstName $lastName"
}

object Director {
  def older(director1: Director, director2: Director): Director =
    if (director1.yearOfBirth < director2.yearOfBirth) director1 else director2
}

case class Film(
  name: String,
  yearOfRelease: Int,
  imdbRating: Double,
  director: Director) {

  def directorsAge =
    yearOfRelease - director.yearOfBirth

  def isDirectedBy(director: Director) =
    this.director == director
}

object Film {
  def newer(film1: Film, film2: Film): Film =
    if (film1.yearOfRelease < film2.yearOfRelease) film1 else film2

  def highestRating(film1: Film, film2: Film): Double = {
    val rating1 = film1.imdbRating
    val rating2 = film2.imdbRating
    if (rating1 > rating2) rating1 else rating2
  }

  def oldestDirectorAtTheTime(film1: Film, film2: Film): Director =
    if (film1.directorsAge > film2.directorsAge) film1.director else film2.director
}

3.4.5.3 ケースクラスカウンター

ケースクラスとして Counter を再実装し、適切なところで copy を使用してください。さらに、0 をデフォルト値として count を初期化しましょう。

case class Counter(count: Int = 0) {
  def dec = copy(count = count - 1)
  def inc = copy(count = count + 1)
}

Counter(0) // `new` なしでオブジェクトを構築
// res16: Counter = Counter(0)

Counter().inc // 印字で `count` の値を表示
// res17: Counter = Counter(1)

Counter().inc.dec == Counter().dec.inc // 意味のある等価性を検証
// res18: Boolean = true

3.4.5.4 適用、適用、適用

ケースクラスにコンパニオンオブジェクトを定義すると何が起こるでしょうか？見てみましょう。

前節の Person クラスを題材に、ケースクラスへの変換を試してみましょう。（ヒント：コードは上にあります。）代替 apply メソッドを伴うコンパニオンオブジェクトを依然として持っていることを確認してください。

case class Person(firstName: String, lastName: String) {
  def name = firstName + " " + lastName
}

object Person {
  def apply(name: String): Person = {
    val parts = name.split(" ")
    apply(parts(0), parts(1))
  }
}

def apply(name: String): Person =
  // etc...

def apply(firstName: String, lastName: String): Person =
  // etc...

3.5 パターンマッチング

これまでは、メソッドを呼び出したり、フィールドにアクセスしたりしてオブジェクトを作用させてきました。ケースクラスを使用すると、パターンマッチング (pattern matching) を通じた別の方法で作用させることができます。

パターンマッチングは、データの「形」に応じて式を評価できるように拡張した if 式のようなものです。前の例で見た Person ケースクラスを思い出してください。

case class Person(firstName: String, lastName: String)

反乱軍のメンバーを探している Stormtrooper を実装したいとしましょう。下記のようにパターンマッチングを使用することができます。

object Stormtrooper {
  def inspect(person: Person): String =
    person match {
      case Person("Luke", "Skywalker") => "Stop, rebel scum!"
      case Person("Han", "Solo") => "Stop, rebel scum!"
      case Person(first, last) => s"Move along, $first"
    }
}

パターンの文法 Person("Luke", "Skywalker") は、パターンマッチングするオブジェクトを構築するための文法 Person("Luke", "Skywalker") と一致していることに注意してください。

使用例はこちらです。

Stormtrooper.inspect(Person("Noel", "Welsh"))
// res0: String = Move along, Noel

Stormtrooper.inspect(Person("Han", "Solo"))
// res1: String = Stop, rebel scum!

expr0 match {
  case pattern1 => expr1
  case pattern2 => expr2
  ...
}

3.5.1 パターン文法

Scala は、パターンやガードを記述するための表現力豊かな文法を持っています。ケースクラスの場合、パターン文法はコンストラクター文法と一致します。データを取り上げてみましょう。

Person("Noel", "Welsh")
// res2: Person = Person(Noel,Welsh)

Person 型に対してマッチするパターンは、下記のように記述されます。

Person(pat0, pat1)

ここで、pat0 と pat1 は、それぞれ firstName と lastName に対してマッチするパターンです。pat0 と pat1 の位置に使用できるパターンは4つあります。

1. 名前。それは、その位置にある任意の値にマッチし、与えられた名前に束縛されます。例えば、パターン Person(first, last) は、名前 first に値 "Noel" を、名前 last に値 "Welsh" を束縛します。

2. アンダースコア (_)。それは、任意の値にマッチし、その値を無視します。例えば、ストームトルーパーが一般市民の名についてのみ気にするのであれば、lastName の値を名前に束縛することを避け、単に Person(first, _) と書くことができます。

3. リテラル。それは、単にリテラルが表現する値に首尾よくマッチします。例えば、パターン Person("Han", "Solo") は、名が "Han" で、姓が "Solo" である Person にマッチするというわけです。

4. 同様のコンストラクタースタイル文法を使用している別のケースクラス。（訳注：ケースクラスを入れ子にできるということです。本節の演習に例があります。）

パターンマッチングでできることは他にもたくさんあり、パターンマッチングは拡張可能であることも覚えておいてください。後ほどの節でそれらの機能を見ていきます。

3.5.2 覚えておいてほしいこと

ケースクラスは、パターンマッチングと呼ばれる相互作用の新しい形を可能にします。パターンマッチングでは、ケースクラスによって分析し、ケースクラスに含まれる内容に応じて異なる式を評価することができます。

パターンマッチングのための文法は、

expr0 match {
  case pattern1 => expr1
  case pattern2 => expr2
  ...
}

です。パターンは、下記のいずれかになります。

1. 名前。その名前に任意の値が束縛される
2. アンダースコア。任意の値がマッチし、その値は無視される
3. リテラル。リテラルが意味する値にマッチする
4. ケースクラスによるコンストラクタースタイルパターン

3.5.3 演習

3.5.3.1 猫にエサをあげる

willServe メソッドを伴う ChipShop オブジェクトを定義してください。このメソッドは Cat を受け取り、猫の好きなエサがカリカリ (chips) であれば true を、そうでなければ false を返します。パターンマッチングを使用しましょう。

case class Cat(name: String, colour: String, food: String)

object ChipShop {
  def willServe(cat: Cat): Boolean =
    cat match {
      case Cat(???, ???, ???) => ???
    }
}

object ChipShop {
  def willServe(cat: Cat): Boolean =
    cat match {
      case Cat(_, _, "Chips") => true
      case Cat(_, _, _) => false
    }
}

3.5.3.2 私の芝生から出ていけ！

この演習では、映画評論家である私の父のシミュレーターを書こうと思います。それはとても単純で、クリント・イーストウッドが監督した映画はどれでも10.0、ジョン・マクティアナンが監督した映画はどれでも7.0、ほかの映画はどれでも3.0に評価されます。Film を受け取り、Double を返す rate メソッドを伴う Dad と呼ばれるオブジェクトを実装してください。パターンマッチングを使用しましょう。

object Dad {
  def rate(film: Film): Double =
    film match {
      case Film(_, _, _, Director("Clint", "Eastwood", _)) => 10.0
      case Film(_, _, _, Director("John", "McTiernan", _)) => 7.0
      case _ => 3.0
    }
}

3.6 まとめ

本章ではクラスを探求しました。そのクラスが、オブジェクトを超えた抽象化を可能にすることも見てきました。それによって、共通のプロパティを共有し、共通の型を持つオブジェクトを定義できます。

コンパニオンオブジェクトについてもまた見てきました。それは、Scala において、補助コンストラクターや、クラスに属さないユーティリティメソッドを定義するために使用されます。

最後に、ケースクラスを紹介しました。それは、ボイラープレートコードを大いに削減し、メソッド呼び出しに加えて、パターンマッチングというオブジェクトとの新しい相互作用の方法を可能にしました。

4 トレイトによるデータモデリング

前章では、クラスについて詳細に見てきました。クラスは、同じ形のプロパティを持つオブジェクトを横断的に抽象化する方法を提供し、クラス内のどのようなオブジェクトでも動作するコードを書くことを可能にします。

本章では、クラスを横断的に抽象化することを探求します。それは、異なるクラスのオブジェクトで動作するコードを書くことを可能にします。これを、トレイト (trait) と呼ばれる機構で実現します。

また、本章は視点を変更する章になります。以前の章では、Scala コードを構築するための技術的側面に取り組んできました。本章の最初こそトレイトの技術的側面に焦点を当てますが、その焦点は思考を表現するための手段として Scala を使用することに変化していきます。

さらに、代数的データ型 (algebraic datatype) と呼ばれるデータの記述をどのように機械的にコードに変換できるかを見ていきます。また、構造的再帰 (structural recursion) を使用して、代数的データ型を変換するコードを機械的に書けることも合わせて見ていきます。

4.1 トレイト

オブジェクトを生成するためのテンプレートであるクラスと同じように、トレイトはクラスを生成するためのテンプレートです。トレイトは、2つ以上のクラスを同じものとみなし、同じ操作を実装するという表現を可能にします。言い換えれば、トレイトは、すべてのクラスが共有している Any 基底型の外側で、共通の基底型を共有する複数のクラスを表現できるということです。

4.1.1 トレイトの例

トレイトの例から始めましょう。Web サイトの訪問者をモデリングすることを想像してください。訪問者には2つのタイプがあり、ひとつはサイトに登録済みの訪問者で、もうひとつは匿名の訪問者です。2つのクラスでこれをモデル化します。

import java.util.Date

case class Anonymous(id: String, createdAt: Date = new Date())

case class User(
  id: String,
  email: String,
  createdAt: Date = new Date()
)

これらのクラス定義で、匿名訪問者と登録済み訪問者は、ID と作成日を持つと言えます。しかし、私たちは登録済み訪問者のメールアドレスしかわかりません。

ここには明らかな重複があり、同じ定義を2回書かない方が望ましいです。しかし、もっと重要なのは、2種類の訪問者のために何らかの共通の型を作るということです。AnyRef や Any ではない、何らかの共通の型を持てれば、どんな種類の訪問者でも動作するメソッドを書くことができます。それは、下記のようにトレイトで実現できます。

import java.util.Date

trait Visitor {
  def id: String      // 各ユーザーに付与される一意の ID
  def createdAt: Date // ユーザーがサイトに初めて訪れた日付

  // この訪問者が初めて訪れてからどのくらいになるのか？
  def age: Long = new Date().getTime - createdAt.getTime
}

case class Anonymous(
  id: String,
  createdAt: Date = new Date()
) extends Visitor

case class User(
  id: String,
  email: String,
  createdAt: Date = new Date()
) extends Visitor

2つの変更に注目してください。

• Visitor トレイトを定義しました
• extends キーワードを使用することによって Visitor トレイトの派生型として Anonymous と User を宣言しました

Visitor トレイトは、どんな派生型でも必ず実装しなければならないインターフェイスを表現するので、String 型の id と Date 型の createdAt を実装しなければなりません。また、Visitor のどんな派生型でも、自動的に Visitor で定義されている age メソッドを持ちます。

Visitor トレイトを定義することによって、下記のように訪問者のどんな派生型でも動作するメソッドを書くことができます。

def older(v1: Visitor, v2: Visitor): Boolean =
  v1.createdAt.before(v2.createdAt)

older(Anonymous("1"), User("2", "test@example.com"))
// res5: Boolean = true

こちらの older メソッドは、Visitor の派生型である Anonymous と User のいずれでも呼び出すことができます。

trait TraitName {
  declarationOrExpression ...
}

class Name(...) extends TraitName {
  ...
}

case class Name(...) extends TraitName {
 ...
}

4.1.2 トレイトとクラスの比較

クラスのように、トレイトはフィールド定義とメソッド定義の名前付き集合です。しかしながら、いくつかの重要な点においてトレイトはクラスと異なっています。

• トレイトはコンストラクターを持てません。トレイトから直接オブジェクトを生成することはできません。その代わりにトレイトを使用してクラスを作ることができ、そのクラスからオブジェクトを生成します。トレイトに基づいたたくさんのクラスを構築できます。

• トレイトは抽象メソッド を定義でき、それは名前と型シグネチャを持ちますが実装は持ちません。これを Visitor トレイトで見ました。トレイトを継承したクラスを作成するときは必ず実装を記述する必要があります。しかし、継承したクラスを作成するときまでは定義を抽象的なままにしておけます。

抽象的な定義のより深く探索するために Visitor トレイトに立ち返ってみましょう。Visitor の定義を思い出してください。

import java.util.Date

trait Visitor {
  def id: String      // 各ユーザーに付与される一意の ID
  def createdAt: Date // ユーザーがサイトに初めて訪れた日付

  // この訪問者が初めて訪れてからどのくらいになるのか？
  def age: Long = new Date().getTime - createdAt.getTime
}

Visitor は2つの抽象メソッドを規定しています。そのメソッドは実装を持っていませんが、派生クラスでは必ず実装しなければなりません。それらは id と createdAt です。また、age という具象メソッドも定義しており、それは抽象メソッドのひとつを使用して定義されています。

Visitor は、Anonymous と User の2つのクラスの構成要素として使用されています。Visitor を継承 (extends) した各クラスは、そのすべてのフィールドとメソッドを継承していることを意味します。

val anon = Anonymous("anon1")
// anon: Anonymous = Anonymous(anon1,Sat Jun 20 09:15:55 UTC 2020)

anon.createdAt
// res7: java.util.Date = Sat Jun 20 09:15:55 UTC 2020

anon.age
// res8: Long = 281

id と createdAt は抽象なので、派生クラスにおいて必ず定義されなければなりません。私たちのクラスでは、def の代わりに val によってそれらを実装しています。Scala においてこれは認められており、def を val のより一般的なバージョンと見なしています⁶。これはよい習慣で、トレイトにおいては val で絶対に定義せず、def を使用してください。これによって、具象実装では適切に def か val を使用して実装できます。

4.1.3 覚えておいてほしいこと

トレイトは、クラスがオブジェクトを横断的に抽象化するための方法であるように、類似のプロパティを持つクラスを横断的に抽象化する方法です。

トレイトを使用するには、2つの段階があります。まずは、トレイトを宣言します。

trait TraitName {
  declarationOrExpression ...
}

そして、クラス（普通はケースクラス）でトレイトを継承します。

case class Name(...) extends TraitName {
  ...
}

4.1.4 演習

4.1.4.1 猫、もっと猫

Cat Simulator 1.0 への需要が爆発的に高まっています！バージョン2では、家庭の猫を越えて、トラ (Tiger) やライオン (Lion)、パンサー (Panther) をイエネコ (Cat) に加えてモデル化します。Feline トレイトを定義し、ネコ科 (Feline) の派生型として、すべての異なる種を定義します。面白くするために、

• これまでのように、Feline に colour を
• Feline に、イエネコであれば "meow"、それ以外すべてのネコ科であれば "roar" である鳴き声 (sound) を String で
• Cat には好きな食べ物を
• Lion にはタテガミの大きさ (maneSize) を Int で

定義します。

trait Feline {
  def colour: String
  def sound: String
}

case class Lion(colour: String, maneSize: Int) extends Feline {
  val sound = "roar"
}

case class Tiger(colour: String) extends Feline {
  val sound = "roar"
}

case class Panther(colour: String) extends Feline {
  val sound = "roar"
}

case class Cat(colour: String, food: String) extends Feline {
  val sound = "meow"
}

trait Feline {
  def colour: String
  def sound: String = "roar"
}

trait BigCat extends Feline {
  override val sound = "roar"
}

case class Tiger(...) extends BigCat
case class Lion(...) extends BigCat
case class Panther(...) extends BigCat

4.1.4.2 トレイトでシェイプアップ

Shape と呼ばれるトレイトを定義し、3つの抽象メソッドをそれに持たせます。

• sides は、辺 (side) の数を返す
• perimeter は、周の長さ (perimeter) を返す
• area は、面積 (area) を返す

図形 (Shape) を3つのクラス、円 (Circle) ・長方形 (Rectangle)・正方形 (Square) で実装します。それぞれの場合で、3つのメソッドについての実装をそれぞれ提供します。各図形のメインコンストラクターの引数（例えば、円の半径）は、フィールドとしてアクセス可能であることを確実にしてください。

ヒント： π の値は math.Pi として参照します。

trait Shape {
  def sides: Int
  def perimeter: Double
  def area: Double
}

case class Circle(radius: Double) extends Shape {
  val sides = 1
  val perimeter = 2 * math.Pi * radius
  val area = math.Pi * radius * radius
}

case class Rectangle(
  width: Double,
  height: Double
) extends Shape {
  val sides = 4
  val perimeter = 2 * width + 2 * height
  val area = width * height
}

case class Square(size: Double) extends Shape {
  val sides = 4
  val perimeter = 4 * size
  val area = size * size
}

4.1.4.3 トレイトでシェイプアップ 2

前回の演習の解答は、図形について別々の3つの型を与えました。しかしながら、それは3つの間にある関係性を正しくモデル化できていません。正方形 (Square) は、単に図形 (Shape) ではなく、幅と高さが同じ長方形の型でもあります。

前回の演習の解答を、正方形 (Square) と長方形 (Rectangle) が共通の型、方形 (Rectangular) の派生型であるようにリファクタリングしてみましょう。

ヒント：トレイトは別のトレイトを継承できます。

// trait Shape ...

// case class Circle ...

sealed trait Rectangular extends Shape {
  def width: Double
  def height: Double
  val sides = 4
  override val perimeter = 2*width + 2*height
  override val area = width*height
}

case class Square(size: Double) extends Rectangular {
  val width = size
  val height = size
}

case class Rectangle(
  val width: Double,
  val height: Double
) extends Rectangular

4.2 This or That and Nothing Else: Sealed Traits

In many cases we can enumerate all the possible classes that can extend a trait. For example, we previously modelled a website visitor as Anonymous or a logged in User. These two cases cover all the possibilities as one is the negation of the other. We can model this case with a sealed trait, which allows the compiler to provide extra checks for us.

We create a sealed trait by simply writing sealed in front of our trait declaration:

import java.util.Date

sealed trait Visitor {
  def id: String
  def createdAt: Date
  def age: Long = new Date().getTime() - createdAt.getTime()
}

When we mark a trait as sealed we must define all of its subtypes in the same file. Once the trait is sealed, the compiler knows the complete set of subtypes and will warn us if a pattern matching expression is missing a case:

def missingCase(v: Visitor) =
  v match {
    case User(_, _, _) => "Got a user"
  }
// <console>:17: warning: match may not be exhaustive.
// It would fail on the following input: Anonymous(_, _)
//          v match {
//          ^
// error: No warnings can be incurred under -Xfatal-warnings.

We will not get a similar warning from an unsealed trait.

We can still extend the subtypes of a sealed trait outside of the file where they are defined. For example, we could extend User or Anonymous further elsewhere. If we want to prevent this possibility we should declare them as sealed (if we want to allow extensions within the file) or final if we want to disallow all extensions. For the visitors example it probably doesn’t make sense to allow any extension to User or Anonymous, so the simplified code should look like this:

sealed trait Visitor { /* ... */ }
final case class User(/* ... */) extends Visitor
final case class Anonymous(/* ... */) extends Visitor

This is a very powerful pattern and one we will use frequently.

sealed trait TraitName {
  ...
}

final case class Name(...) extends TraitName {
  ...
}

4.2.1 Take home points

Sealed traits and final (case) classes allow us to control extensibility of types. The majority of cases should use the sealed trait / final case class pattern.

sealed trait TraitName { ... }
final case class Name(...) extends TraitName

The main advantages of this pattern are:

• the compiler will warn if we miss a case in pattern matching; and
• we can control extension points of sealed traits and thus make stronger guarantees about the behaviour of subtypes.

4.2.2 Exercises

4.2.2.1 Printing Shapes

Let’s revisit the Shapes example from Section [@sec:traits:shaping-up-2].

First make Shape a sealed trait. Then write a singleton object called Draw with an apply method that takes a Shape as an argument and returns a description of it on the console. For example:

Draw(Circle(10))
// res1: String = A circle of radius 10.0cm

Draw(Rectangle(3, 4))
// res2: String = A rectangle of width 3.0cm and height 4.0cm

Finally, verify that the compiler complains when you comment out a case clause.

object Draw {
  def apply(shape: Shape): String = shape match {
    case Rectangle(width, height) =>
      s"A rectangle of width ${width}cm and height ${height}cm"

    case Square(size) =>
      s"A square of size ${size}cm"

    case Circle(radius) =>
      s"A circle of radius ${radius}cm"
  }
}

4.2.2.2 The Color and the Shape

Write a sealed trait Color to make our shapes more interesting.

• give Color three properties for its RGB values;
• create three predefined colours: Red, Yellow, and Pink;
• provide a means for people to produce their own custom Colors with their own RGB values;
• provide a means for people to tell whether any Color is “light” or “dark”.

A lot of this exercise is left deliberately open to interpretation. The important thing is to practice working with traits, classes, and objects.

Decisions such as how to model colours and what is considered a light or dark colour can either be left up to you or discussed with other class members.

Edit the code for Shape and its subtypes to add a colour to each shape.

Finally, update the code for Draw.apply to print the colour of the argument as well as its shape and dimensions:

• if the argument is a predefined colour, print that colour by name:

Draw(Circle(10, Yellow))
// res8: String = A yellow circle of radius 10.0cm

• if the argument is a custom colour rather than a predefined one, print the word “light” or “dark” instead.

You may want to deal with the colour in a helper method.

// Shape uses Color so we define Color first:
sealed trait Color {
  // We decided to store RGB values as doubles between 0.0 and 1.0.
  //
  // It is always good practice to define abstract members as `defs`
  // so we can implement them with `defs`, `vals` or `vars`.
  def red: Double
  def green: Double
  def blue: Double

  // We decided to define a "light" colour as one with
  // an average RGB of more than 0.5:
  def isLight = (red + green + blue) / 3.0 > 0.5
  def isDark = !isLight
}

case object Red extends Color {
  // Here we have implemented the RGB values as `vals`
  // because the values cannot change:
  val red = 1.0
  val green = 0.0
  val blue = 0.0
 }

case object Yellow extends Color {
  // Here we have implemented the RGB values as `vals`
  // because the values cannot change:
  val red = 1.0
  val green = 1.0
  val blue = 0.0
}

case object Pink extends Color {
  // Here we have implemented the RGB values as `vals`
  // because the values cannot change:
  val red = 1.0
  val green = 0.0
  val blue = 1.0
}

// The arguments to the case class here generate `val` declarations
// that implement the RGB methods from `Color`:
final case class CustomColor(
  red: Double,
  green: Double,
  blue: Double) extends Color

// The code from the previous exercise comes across almost verbatim,
// except that we add a `color` field to `Shape` and its subtypes:
sealed trait Shape {
  def sides: Int
  def perimeter: Double
  def area: Double
  def color: Color
}

final case class Circle(radius: Double, color: Color) extends Shape {
  val sides = 1
  val perimeter = 2 * math.Pi * radius
  val area = math.Pi * radius * radius
}

sealed trait Rectangular extends Shape {
  def width: Double
  def height: Double
  val sides = 4
  val perimeter = 2 * width + 2 * height
  val area = width * height
}

final case class Square(size: Double, color: Color) extends Rectangular {
  val width = size
  val height = size
}

final case class Rectangle(
  width: Double,
  height: Double,
  color: Color
) extends Rectangular

// We decided to overload the `Draw.apply` method for `Shape` and
// `Color` on the basis that we may want to reuse the `Color` code
// directly elsewhere:
object Draw {
  def apply(shape: Shape): String = shape match {
    case Circle(radius, color) =>
      s"A ${Draw(color)} circle of radius ${radius}cm"

    case Square(size, color) =>
      s"A ${Draw(color)} square of size ${size}cm"

    case Rectangle(width, height, color) =>
      s"A ${Draw(color)} rectangle of width ${width}cm and height ${height}cm"
  }

  def apply(color: Color): String = color match {
    // We deal with each of the predefined Colors with special cases:
    case Red    => "red"
    case Yellow => "yellow"
    case Pink   => "pink"
    case color  => if(color.isLight) "light" else "dark"
  }
}

// Test code:

Draw(Circle(10, Pink))
// res29: String = A pink circle of radius 10.0cm

Draw(Rectangle(3, 4, CustomColor(0.4, 0.4, 0.6)))
// res30: String = A dark rectangle of width 3.0cm and height 4.0cm

4.2.2.3 A Short Division Exercise

Good Scala developers don’t just use types to model data. Types are a great way to put artificial limitations in place to ensure we don’t make mistakes in our programs. In this exercise we will see a simple (if contrived) example of this—using types to prevent division by zero errors.

Dividing by zero is a tricky problem—it can lead to exceptions. The JVM has us covered as far as floating point division is concerned but integer division is still a problem:

1.0 / 0.0
// res31: Double = Infinity

1 / 0
// java.lang.ArithmeticException: / by zero
//   ... 1024 elided

Let’s solve this problem once and for all using types!

Create an object called divide with an apply method that accepts two Ints and returns DivisionResult. DivisionResult should be a sealed trait with two subtypes: a Finite type encapsulating the result of a valid division, and an Infinite type representing the result of dividing by 0.

Here’s some example usage:

val x = divide(1, 2)
// x: DivisionResult = Finite(0)

val y = divide(1, 0)
// y: DivisionResult = Infinite

Finally, write some sample code that calls divide, matches on the result, and returns a sensible description.

sealed trait DivisionResult
final case class Finite(value: Int) extends DivisionResult
case object Infinite extends DivisionResult

object divide {
  def apply(num: Int, den: Int): DivisionResult =
    if(den == 0) Infinite else Finite(num / den)
}

divide(1, 0) match {
  case Finite(value) => s"It's finite: ${value}"
  case Infinite      => s"It's infinite"
}
// res34: String = It's infinite

4.3 Modelling Data with Traits

In this section we’re going to shift our focus from language features to programming patterns. We’re going to look at modelling data and learn a process for expressing in Scala any data model defined in terms of logical ors and ands. Using the terminology of object-oriented programming, we will express is-a and has-a relationships. In the terminology of functional programming we are learning about sum and product types, which are together called algebraic data types.

Our goal in this section is to see how to translate a data model into Scala code. In the next section we’ll see patterns for code that uses algebraic data types.

4.3.1 The Product Type Pattern

Our first pattern is to model data that contains other data. We might describe this as “A has a B and C”. For example, a Cat has a colour and a favourite food; a Visitor has an id and a creation date; and so on.

The way we write this is to use a case class. We’ve already done this many times in exercises; now we’re formalising the pattern.

case class A(b: B, c: C)

trait A {
  def b: B
  def c: C
}

4.4 The Sum Type Pattern

Our next pattern is to model data that is two or more distinct cases. We might describe this as “A is a B or C”. For example, a Feline is a Cat, Lion, or Tiger; a Visitor is an Anonymous or User; and so on.

We write this using the sealed trait / final case class pattern.

sealed trait A
final case class B() extends A
final case class C() extends A

4.4.1 Algebraic Data Types

An algebraic data type is any data that uses the above two patterns. In the functional programming literature, data using the “has-a and” pattern is known as a product type, and the “is-a or” pattern is a sum type.

4.4.2 The Missing Patterns

We have looked at relationships along two dimensions: is-a/has-a, and and/or. We can draw up a little table and see we only have patterns for two of the four table cells.

What about the missing two patterns?

The “is-a and” pattern means that A is a B and C. This pattern is in some ways the inverse of the sum type pattern, and we can implement it as

trait B
trait C
trait A extends B with C

In Scala a trait can extend as many traits as we like using the with keyword like A extends B with C with D and so on. We aren’t going to use this pattern in this course. If we want to represent that some data conforms to a number of different interfaces we will often be better off using a type class, which we will explore later. There are, however, several legitimate uses of this pattern:

• for modularity, using what’s known as the cake pattern; and
• sharing implementation across several classes where it doesn’t make sense to make default implementations in the main trait.

The “has-a or” patterns means that A has a B or C. There are two ways we can implement this. We can say that A has a d of type D, where D is a B or C. We can mechanically apply our two patterns to implement this:

trait A {
  def d: D
}
sealed trait D
final case class B() extends D
final case class C() extends D

Alternatively we could implement this as A is a D or E, and D has a B and E has a C. Again this translates directly into code

sealed trait A
final case class D(b: B) extends A
final case class E(c: C) extends A

4.4.3 Take Home Points

We have seen that we can mechanically translate data using the “has-a and” and “is-a or” patterns (or, more succinctly, the product and sum types) into Scala code. This type of data is known as an algebraic data type. Understanding these patterns is very important for writing idiomatic Scala code.

4.4.4 Exercises

4.4.4.1 Stop on a Dime

A traffic light is red, green, or yellow. Translate this description into Scala code.

sealed trait TrafficLight
case object Red extends TrafficLight
case object Green extends TrafficLight
case object Yellow extends TrafficLight

4.4.4.2 Calculator

A calculation may succeed (with an Int result) or fail (with a String message). Implement this.

sealed trait Calculation
final case class Success(result: Int) extends Calculation
final case class Failure(reason: String) extends Calculation

4.4.4.3 Water, Water, Everywhere

Bottled water has a size (an Int), a source (which is a well, spring, or tap), and a Boolean carbonated. Implement this in Scala.

sealed trait Source
case object Well extends Source
case object Spring extends Source
case object Tap extends Source
final case class BottledWater(size: Int, source: Source, carbonated: Boolean)

4.5 Working With Data

In the previous section we saw how to define algebraic data types using a combination of the sum (or) and product type (and) patterns. In this section we’ll see a pattern for using algebraic data types, known as structural recursion. We’ll actually see two variants of this pattern: one using polymorphism and one using pattern matching.

Structural recursion is the precise opposite of the process of building an algebraic data type. If A has a B and C (the product-type pattern), to construct an A we must have a B and a C. The sum and product type patterns tell us how to combine data to make bigger data. Structural recursion says that if we have an A as defined before, we must break it into its constituent B and C that we then combine in some way to get closer to our desired answer. Structural recursion is essentially the process of breaking down data into smaller pieces.

Just as we have two patterns for building algebraic data types, we will have two patterns for decomposing them using structural recursion. We will actually have two variants of each pattern, one using polymorphism, which is the typical object-oriented style, and one using pattern matching, which is typical functional style. We’ll end this section with some rules for choosing which pattern to use.

4.5.1 Structural Recursion using Polymorphism

Polymorphic dispatch, or just polymorphism for short, is a fundamental object-oriented technique. If we define a method in a trait, and have different implementations in classes extending that trait, when we call that method the implementation on the actual concrete instance will be used. Here’s a very simple example. We start with a simple definition using the familiar sum type (or) pattern.

sealed trait A {
  def foo: String
}
final case class B() extends A {
  def foo: String =
    "It's B!"
}
final case class C() extends A {
  def foo: String =
    "It's C!"
}

We declare a value with type A but we see the concrete implementation on B or C is used.

val anA: A = B()
// anA: A = B()

anA.foo
// res0: String = It's B!

val anA: A = C()
// anA: A = C()

anA.foo
// res1: String = It's C!

We can define an implementation in a trait, and change the implementation in an extending class using the override keyword.

sealed trait A {
  def foo: String =
    "It's A!"
}
final case class B() extends A {
  override def foo: String =
    "It's B!"
}
final case class C() extends A {
  override def foo: String =
    "It's C!"
}

The behaviour is as before; the implementation on the concrete class is selected.

val anA: A = B()
// anA: A = B()

anA.foo
// res2: String = It's B!

Remember that if you provide a default implementation in a trait, you should ensure that implementation is valid for all subtypes.

Now we understand how polymorphism works, how do we use it with an algebraic data types? We’ve actually seen everything we need, but let’s make it explicit and see the patterns.

case class A(b: B, c: C) {
  def f: F = ???
}

sealed trait A {
  def f: F
}
final case class B() extends A {
  def f: F =
    ???
}
final case class C() extends A {
  def f: F =
    ???
}

4.5.2 Structural Recursion using Pattern Matching

Structural recursion with pattern matching proceeds along the same lines as polymorphism. We simply have a case for every subtype, and each pattern matching case must extract the fields we’re interested in.

def f(a: A): F =
  a match {
    case A(b, c) => ???
  }

def f(a: A): F =
  a match {
    case B() => ???
    case C() => ???
  }

4.5.3 A Complete Example

Let’s look at a complete example of the algebraic data type and structural recursion patterns, using our familiar Feline data type.

We start with a description of the data. A Feline is a Lion, Tiger, Panther, or Cat. We’re going to simplify the data description, and just say that a Cat has a String favouriteFood. From this description we can immediately apply our pattern to define the data.

sealed trait Feline
final case class Lion() extends Feline
final case class Tiger() extends Feline
final case class Panther() extends Feline
final case class Cat(favouriteFood: String) extends Feline

Now let’s implement a method using both polymorphism and pattern matching. Our method, dinner, will return the appropriate food for the feline in question. For a Cat their dinner is their favouriteFood. For Lions it is antelope, for Tigers it is tiger food, and for Panthers it is licorice.

We could represent food as a String, but we can do better and represent it with a type. This avoids, for example, spelling mistakes in our code. So let’s define our Food type using the now familiar patterns.

sealed trait Food
case object Antelope extends Food
case object TigerFood extends Food
case object Licorice extends Food
final case class CatFood(food: String) extends Food

Now we can implement dinner as a method returning Food. First using polymorphism:

sealed trait Feline {
  def dinner: Food
}
final case class Lion() extends Feline {
  def dinner: Food =
    Antelope
}
final case class Tiger() extends Feline {
  def dinner: Food =
    TigerFood
}
final case class Panther() extends Feline {
  def dinner: Food =
    Licorice
}
final case class Cat(favouriteFood: String) extends Feline {
  def dinner: Food =
    CatFood(favouriteFood)
}

Now using pattern matching. We actually have two choices when using pattern matching. We can implement our code in a single method on Feline or we can implement it in a method on another object. Let’s see both.

sealed trait Feline {
  def dinner: Food =
    this match {
      case Lion() => Antelope
      case Tiger() => TigerFood
      case Panther() => Licorice
      case Cat(favouriteFood) => CatFood(favouriteFood)
    }
}

object Diner {
  def dinner(feline: Feline): Food =
    feline match {
      case Lion() => Antelope
      case Tiger() => TigerFood
      case Panther() => Licorice
      case Cat(food) => CatFood(food)
    }
}

Note how we can directly apply the patterns, and the code falls out. This is the main point we want to make with structural recursion: the code follows the shape of the data, and can be produced in an almost mechanical way.

4.5.4 Choosing Which Pattern to Use

We have three way of implementing structural recursion:

1. polymorphism;
2. pattern matching in the base trait; and
3. pattern matching in an external object (as in the Diner example above).

Which should we use? The first two methods give the same result: a method defined on the classes of interest. We should use whichever is more convenient. This normally ends up being pattern matching on the base trait as it requires less code duplication.

When we implement a method in the classes of interest we can have only one implementation of the method, and everything that method requires to work must be contained within the class and parameters we pass to the method. When we implement methods using pattern matching in an external object we can provide multiple implementations, one per object (multiple Diners in the example above).

The general rule is: if a method only depends on other fields and methods in a class it is a good candidate to be implemented inside the class. If the method depends on other data (for example, if we needed a Cook to make dinner) consider implementing it using pattern matching outside of the classes in question. If we want to have more than one implementation we should use pattern matching and implement it outside the classes.

4.5.5 Object-Oriented vs Functional Extensibility

In classic functional programming style we have no objects, only data without methods and functions. This style of programming makes extensive use of pattern matching. We can mimic it in Scala using the algebraic data type pattern and pattern matching in methods defined on external objects.

Classic object oriented style uses polymorphism and allow open extension of classes. In Scala terms this means no sealed traits.

What are the tradeoffs we make in the two different styles?

One advantage of functional style is it allows the compiler to help us more. By sealing traits we are telling the compiler it knows all the possible subtypes of that trait. It can then tell us if we miss out a case in our pattern matching. This is especially useful if we add or remove subtypes later in development. We could argue we get the same benefit from object-oriented style, as we must implement all methods defined on the base trait in any subtypes. This is true, but in practice classes with a large number of methods are very difficult to maintain and we’ll inevitably end up factoring some of the code into different classes – essentially duplicating the functional style.

This doesn’t mean functional style is to be preferred in all cases. There is a fundamental difference between the kind of extensibility that object-oriented style and functional style gives us. With OO style we can easily add new data, by extending a trait, but adding a new method requires us to change existing code. With functional style we can easily add a new method but adding new data requires us to modify existing code. In tabular form:

In Scala we have the flexibility to use both polymorphism and pattern matching, and we should use whichever is appropriate. However we generally prefer sealed traits as it gives us greater guarantees about our code’s semantics, and we can use typeclasses, which we’ll explore later, to get us OO-style extensibility.

4.5.6 Exercises

4.5.6.1 Traffic Lights

In the previous section we implemented a TrafficLight data type like so:

sealed trait TrafficLight
case object Red extends TrafficLight
case object Green extends TrafficLight
case object Yellow extends TrafficLight

Using polymorphism and then using pattern matching implement a method called next which returns the next TrafficLight in the standard Red -> Green -> Yellow -> Red cycle. Do you think it is better to implement this method inside or outside the class? If inside, would you use pattern matching or polymorphism? Why?

sealed trait TrafficLight {
  def next: TrafficLight
}
case object Red extends TrafficLight {
  def next: TrafficLight =
    Green
}
case object Green extends TrafficLight {
  def next: TrafficLight =
    Yellow
}
case object Yellow extends TrafficLight {
  def next: TrafficLight =
    Red
}

sealed trait TrafficLight {
  def next: TrafficLight =
    this match {
      case Red => Green
      case Green => Yellow
      case Yellow => Red
    }
}
case object Red extends TrafficLight
case object Green extends TrafficLight
case object Yellow extends TrafficLight

4.5.6.2 Calculation

In the last section we created a Calculation data type like so:

sealed trait Calculation
final case class Success(result: Int) extends Calculation
final case class Failure(reason: String) extends Calculation

We’re now going to write some methods that use a Calculation to perform a larger calculation. These methods will have a somewhat unusual shape—this is a precursor to things we’ll be exploring soon—but if you follow the patterns you will be fine.

Create a Calculator object. On Calculator define methods + and - that accept a Calculation and an Int, and return a new Calculation. Here are some examples

assert(Calculator.+(Success(1), 1) == Success(2))
assert(Calculator.-(Success(1), 1) == Success(0))
assert(Calculator.+(Failure("Badness"), 1) == Failure("Badness"))

object Calculator {
  def +(calc: Calculation, operand: Int): Calculation = ???
  def -(calc: Calculation, operand: Int): Calculation = ???
}

object Calculator {
  def +(calc: Calculation, operand: Int): Calculation =
    calc match {
        case Success(result) => ???
        case Failure(reason) => ???
    }
  def -(calc: Calculation, operand: Int): Calculation =
    calc match {
      case Success(result) => ???
      case Failure(reason) => ???
    }
}

object Calculator {
  def +(calc: Calculation, operand: Int): Calculation =
    calc match {
        case Success(result) => Success(result + operand)
        case Failure(reason) => Failure(reason)
    }
  def -(calc: Calculation, operand: Int): Calculation =
    calc match {
      case Success(result) => Success(result - operand)
      case Failure(reason) => Failure(reason)
    }
}

Now write a division method that fails if the divisor is 0. The following tests should pass. Note the behavior for the last test. This indicates “fail fast” behavior. If a calculation has already failed we keep that failure and don’t process any more data even if, as is the case in the test, doing so would lead to another failure.

assert(Calculator./(Success(4), 2) == Success(2))
assert(Calculator./(Success(4), 0) == Failure("Division by zero"))
assert(Calculator./(Failure("Badness"), 0) == Failure("Badness"))

def /(calc: Calculation, operand: Int): Calculation =
  calc match {
    case Success(result) =>
      operand match {
        case 0 => Failure("Division by zero")
        case _ => Success(result / operand)
      }
    case Failure(reason) => Failure(reason)
  }

4.5.6.3 Email

Recall the Visitor trait we looked at earlier: a website Visitor is either Anonymous or a signed-in User. Now imagine we wanted to add the ability to send emails to visitors. We can only email signed-in users, and sending an email requires a lot of knowledge about SMTP settings, MIME headers, and so on. Would an email method be better implemented using polymorphism on the Visitor trait or using pattern matching in an EmailService object? Why?

4.6 Recursive Data

A particular use of algebraic data types that comes up very often is defining recursive data. This is data that is defined in terms of itself, and allows us to create data of potentially unbounded size (though any concrete instance will be finite).

We can’t define recursive data like⁷

final case class Broken(broken: Broken)

as we could never actually create an instance of such a type—the recursion never ends. To define valid recursive data we must define a base case, which is the case that ends the recursion.

Here is a more useful recursive definition: an IntList is either the empty list End, or a Pair⁸ containing an Int and an IntList. We can directly translate this to code using our familiar patterns:

sealed trait IntList
case object End extends IntList
final case class Pair(head: Int, tail: IntList) extends IntList

Here End is the base case. We construct the list containing 1, 2, and 3 as follows:

Pair(1, Pair(2, Pair(3, End)))

This data structure is known as a singly-linked list. In this example we have four links in our chain. We can write this out in a longer form to better understand the structure of the list. Below, d represents an empty list, and a, b, and c are pairs built on top of it.

val d = End()
val c = Pair(3, d)
val b = Pair(2, c)
val a = Pair(1, b)

In addition to being links in a chain, these data structures all represent complete sequences of integers:

• a represents the sequence 1, 2, 3
• b represents the sequence 2, 3
• c represents the sequence 3 (only one element)
• d represents an empty sequence

Using this implementation, we can build lists of arbitrary length by repeatedly taking an existing list and prepending a new element⁹.

We can apply the same structural recursion patterns to process a recursive algebraic data type. The only wrinkle is that we must make a recursive call when the data definition is recursion.

Let’s add together all the elements of an IntList. We’ll use pattern matching, but as we know the same process applies to using polymorphism.

Start with the tests and method declaration.

val example = Pair(1, Pair(2, Pair(3, End)))
assert(sum(example) == 6)
assert(sum(example.tail) == 5)
assert(sum(End) == 0)

def sum(list: IntList): Int = ???

Note how the tests define 0 to be the sum of the elements of an End list. It is important that we define an appropriate base case for our method as we will build our final result of this base case.

Now we apply our structural recursion pattern to fill out the body of the method.

def sum(list: IntList): Int =
  list match {
    case End => ???
    case Pair(hd, tl) => ???
  }

Finally we have to decide on the bodies of our cases. We have already decided that 0 is answer for End. For Pair we have two bits of information to guide us. We know we need to return an Int and we know that we need to make a recursive call on tl. Let’s fill in what we have.

def sum(list: IntList): Int =
  list match {
    case End => 0
    case Pair(hd, tl) => ??? sum(tl)
  }

The recursive call will return the sum of the tail of the list, by definition. Thus the correct thing to do is to add hd to this result. This gives us our final result:

def sum(list: IntList): Int =
  list match {
    case End => 0
    case Pair(hd, tl) => hd + sum(tl)
  }

4.6.1 Understanding the Base Case and Recursive Case

Our patterns will carry us most of the way to a correct answer, but we still need to supply the method bodies for the base and recursive cases. There is some general guidance we can use:

• For the base case we should generally return the identity for the function we’re trying to compute. The identity is an element that doesn’t change the result. E.g. 0 is the identity for addition, because a + 0 == a for any a. If we were calculating the product of elements the identity would be 1 as a * 1 == a for all a.

• For the recursive case, assume the recursion will return the correct result and work out what you need to add to get the correct answer. We saw this for sum, where we assume the recursive call will give us the correct result for the tail of the list and we then just add on the head.

sealed trait RecursiveExample
final case class RecursiveCase(recursion: RecursiveExample) extends RecursiveExample
case object BaseCase extends RecursiveExample

4.6.2 Tail Recursion

You may be concerned that recursive calls will consume excessive stack space. Scala can apply an optimisation, called tail recursion, to many recursive functions to stop them consuming stack space.

A tail call is a method call where the caller immediately returns the value. So this is a tail call

def method1: Int =
  1

def tailCall: Int =
  method1

because tailCall immediately returns the result of calling method1 while

def notATailCall: Int =
  method1 + 2

because notATailCall does not immediatley return—it adds an number to the result of the call.

A tail call can be optimised to not use stack space. Due to limitations in the JVM, Scala only optimises tail calls where the caller calls itself. Since tail recursion is an important property to maintain, we can use the @tailrec annotation to ask the compiler to check that methods we believe are tail recursion really are. Here we have two versions of sum annotated. One is tail recursive and one is not. You can see the compiler complains about the method that is not tail recursive.

import scala.annotation.tailrec

@tailrec
def sum(list: IntList): Int =
  list match {
    case End => 0
    case Pair(hd, tl) => hd + sum(tl)
  }
// <console>:20: error: could not optimize @tailrec annotated method sum: it contains a recursive call not in tail position
//          list match {
//          ^

@tailrec
def sum(list: IntList, total: Int = 0): Int =
  list match {
    case End => total
    case Pair(hd, tl) => sum(tl, total + hd)
  }
// sum: (list: IntList, total: Int)Int

Any non-tail recursion function can be transformed into a tail recursive version by adding an accumulator as we have done with sum above. This transforms stack allocation into heap allocation, which sometimes is a win, and other times is not.

In Scala we tend not to work directly with tail recursive functions as there is a rich collections library that covers the most common cases where tail recursion is used. Should you need to go beyond this, because you’re implementing your own datatypes or are optimising code, it is useful to know about tail recursion.

4.6.3 Exercises

4.6.3.1 A List of Methods

Using our definition of IntList

sealed trait IntList
case object End extends IntList
final case class Pair(head: Int, tail: IntList) extends IntList

define a method length that returns the length of the list. There is test data below you can use to check your solution. For this exercise it is best to use pattern matching in the base trait.

val example = Pair(1, Pair(2, Pair(3, End)))

assert(example.length == 3)
assert(example.tail.length == 2)
assert(End.length == 0)

sealed trait IntList {
  def length: Int =
    this match {
      case End => 0
      case Pair(hd, tl) => 1 + tl.length
    }
}
case object End extends IntList
final case class Pair(head: Int, tail: IntList) extends IntList

Define a method to compute the product of the elements in an IntList. Test cases are below.

assert(example.product == 6)
assert(example.tail.product == 6)
assert(End.product == 1)

sealed trait IntList {
  def product: Int =
    this match {
      case End => 1
      case Pair(hd, tl) => hd * tl.product
    }
}
case object End extends IntList
final case class Pair(head: Int, tail: IntList) extends IntList

Define a method to double the value of each element in an IntList, returning a new IntList. The following test cases should hold:

assert(example.double == Pair(2, Pair(4, Pair(6, End))))
assert(example.tail.double == Pair(4, Pair(6, End)))
assert(End.double == End)

sealed trait IntList {
  def double: IntList =
    this match {
      case End => End
      case Pair(hd, tl) => Pair(hd * 2, tl.double)
    }
}
case object End extends IntList
final case class Pair(head: Int, tail: IntList) extends IntList

4.6.3.2 The Forest of Trees

A binary tree of integers can be defined as follows:

A Tree is a Node with a left and right Tree or a Leaf with an element of type Int.

Implement this algebraic data type.

sealed trait Tree
final case class Node(l: Tree, r: Tree) extends Tree
final case class Leaf(elt: Int) extends Tree

Implement sum and double on Tree using polymorphism and pattern matching.

object TreeOps {
  def sum(tree: Tree): Int =
    tree match {
      case Leaf(elt) => elt
      case Node(l, r) => sum(l) + sum(r)
    }

  def double(tree: Tree): Tree =
    tree match {
      case Leaf(elt) => Leaf(elt * 2)
      case Node(l, r) => Node(double(l), double(r))
    }
}

sealed trait Tree {
  def sum: Int
  def double: Tree
}
final case class Node(l: Tree, r: Tree) extends Tree {
  def sum: Int =
    l.sum + r.sum

  def double: Tree =
    Node(l.double, r.double)
}
final case class Leaf(elt: Int) extends Tree {
  def sum: Int =
    elt

  def double: Tree =
    Leaf(elt * 2)
}

4.7 Extended Examples

To test your skills with algebraic data types and structural recursion here are some larger projects to attempt.

4.7.0.1 A Calculator

In this exercise we’ll implement a simple interpreter for programs containing only numeric operations.

We start by defining some types to represent the expressions we’ll be operating on. In the compiler literature this is known as an abstract syntax tree.

Our representation is:

• An Expression is an Addition, Subtraction, or a Number;
• An Addition has a left and right Expression;
• A Subtraction has a left and right Expression; or
• A Number has a value of type Double.

Implement this in Scala.

sealed trait Expression
final case class Addition(left: Expression, right: Expression) extends Expression
final case class Subtraction(left: Expression, right: Expression) extends Expression
final case class Number(value: Double) extends Expression

Now implement a method eval that converts an Expression to a Double. Use polymorphism or pattern matching as you see fit. Explain your choice of implementation method.

sealed trait Expression {
  def eval: Double =
    this match {
      case Addition(l, r) => l.eval + r.eval
      case Subtraction(l, r) => l.eval - r.eval
      case Number(v) => v
    }
}
final case class Addition(left: Expression, right: Expression) extends Expression
final case class Subtraction(left: Expression, right: Expression) extends Expression
final case class Number(value: Int) extends Expression

We’re now going to add some expressions that call fail: division and square root. Start by extending the abstract syntax tree to include representations for Division and SquareRoot.

sealed trait Expression
final case class Addition(left: Expression, right: Expression) extends Expression
final case class Subtraction(left: Expression, right: Expression) extends Expression
final case class Division(left: Expression, right: Expression) extends Expression
final case class SquareRoot(value: Expression) extends Expression
final case class Number(value: Double) extends Expression

Now we’re going to change eval to represent that a computation can fail. (Double uses NaN to indicate a computation failed, but we want to be helpful to the user and tell them why the computation failed.) Implement an appropriate algebraic data type.

sealed trait Calculation
final case class Success(result: Double) extends Calculation
final case class Failure(reason: String) extends Calculation

Now change eval to return your result type, which I have called Calculation in my implementation. Here are some examples:

assert(Addition(SquareRoot(Number(-1.0)), Number(2.0)).eval ==
       Failure("Square root of negative number"))
assert(Addition(SquareRoot(Number(4.0)), Number(2.0)).eval == Success(4.0))
assert(Division(Number(4), Number(0)).eval == Failure("Division by zero"))

sealed trait Expression {
  def eval: Calculation =
    this match {
      case Addition(l, r) =>
          l.eval match {
            case Failure(reason) => Failure(reason)
            case Success(r1) =>
              r.eval match {
                case Failure(reason) => Failure(reason)
                case Success(r2) => Success(r1 + r2)
              }
          }
      case Subtraction(l, r) =>
          l.eval match {
            case Failure(reason) => Failure(reason)
            case Success(r1) =>
              r.eval match {
                case Failure(reason) => Failure(reason)
                case Success(r2) => Success(r1 - r2)
              }
          }
      case Division(l, r) =>
        l.eval match {
          case Failure(reason) => Failure(reason)
          case Success(r1) =>
            r.eval match {
              case Failure(reason) => Failure(reason)
              case Success(r2) =>
                if(r2 == 0)
                  Failure("Division by zero")
                else
                  Success(r1 / r2)
            }
        }
      case SquareRoot(v) =>
        v.eval match {
          case Success(r) =>
            if(r < 0)
              Failure("Square root of negative number")
            else
              Success(Math.sqrt(r))
          case Failure(reason) => Failure(reason)
        }
      case Number(v) => Success(v)
    }
}
final case class Addition(left: Expression, right: Expression) extends Expression
final case class Subtraction(left: Expression, right: Expression) extends Expression
final case class Division(left: Expression, right: Expression) extends Expression
final case class SquareRoot(value: Expression) extends Expression
final case class Number(value: Int) extends Expression

4.7.0.2 JSON

In the calculator exercise we gave you the algebraic data type representation. In this exercise we want you to design the algebraic data type yourself. We’re going to work in what is hopefully a familiar domain: JSON.

Design an algebraic data type to represent JSON. Don’t go directly to code. Start by sketching out the design in terms of logical ands and ors—the building blocks of algebraic data types. You might find it useful to use a notation similar to BNF. For example, we could represent the Expression data type from the previous exercise as follows:

Expression ::= Addition left:Expression right:Expression
             | Subtraction left:Expression right:Expression
             | Division left:Expression right:Expression
             | SquareRoot value:Expression
             | Number value:Int

This simplified notation allows us to concentrate on the structure of the algebraic data type without worrying about the intricacies of Scala syntax.

Note you’ll need a sequence type to model JSON, and we haven’t looked at Scala’s collection library yet. However we have seen how to implement a list as an algebraic data type.

Here are some examples of JSON you’ll need to be able to represent

["a string", 1.0, true]
{
  "a": [1,2,3],
  "b": ["a","b","c"]
  "c": { "doh":true, "ray":false, "me":1 }
}

Json ::= JsNumber value:Double
       | JsString value:String
       | JsBoolean value:Boolean
       | JsNull
       | JsSequence
       | JsObject
JsSequence ::= SeqCell head:Json tail:JsSequence
             | SeqEnd
JsObject ::= ObjectCell key:String value:Json tail:JsObject
           | ObjectEnd

Translate your representation to Scala code.

sealed trait Json
final case class JsNumber(value: Double) extends Json
final case class JsString(value: String) extends Json
final case class JsBoolean(value: Boolean) extends Json
case object JsNull extends Json
sealed trait JsSequence extends Json
final case class SeqCell(head: Json, tail: JsSequence) extends JsSequence
case object SeqEnd extends JsSequence
sealed trait JsObject extends Json
final case class ObjectCell(key: String, value: Json, tail: JsObject) extends JsObject
case object ObjectEnd extends JsObject

Now add a method to convert your JSON representation to a String. Make sure you enclose strings in quotes, and handle arrays and objects properly.

object json {
  sealed trait Json {
    def print: String = {
      def quote(s: String): String =
        '"'.toString ++ s ++ '"'.toString
      def seqToJson(seq: SeqCell): String =
        seq match {
          case SeqCell(h, t @ SeqCell(_, _)) =>
            s"${h.print}, ${seqToJson(t)}"
          case SeqCell(h, SeqEnd) => h.print
        }

      def objectToJson(obj: ObjectCell): String =
        obj match {
          case ObjectCell(k, v, t @ ObjectCell(_, _, _)) =>
            s"${quote(k)}: ${v.print}, ${objectToJson(t)}"
          case ObjectCell(k, v, ObjectEnd) =>
            s"${quote(k)}: ${v.print}"
        }

      this match {
        case JsNumber(v) => v.toString
        case JsString(v) => quote(v)
        case JsBoolean(v) => v.toString
        case JsNull => "null"
        case s @ SeqCell(_, _) => "[" ++ seqToJson(s) ++ "]"
        case SeqEnd => "[]"
        case o @ ObjectCell(_, _, _) => "{" ++ objectToJson(o) ++ "}"
        case ObjectEnd => "{}"
      }
    }
  }
  final case class JsNumber(value: Double) extends Json
  final case class JsString(value: String) extends Json
  final case class JsBoolean(value: Boolean) extends Json
  case object JsNull extends Json
  sealed trait JsSequence extends Json
  final case class SeqCell(head: Json, tail: JsSequence) extends JsSequence
  case object SeqEnd extends JsSequence
  sealed trait JsObject extends Json
  final case class ObjectCell(key: String, value: Json, tail: JsObject) extends JsObject
  case object ObjectEnd extends JsObject
}

Test your method works. Here are some examples using the representation I chose.

SeqCell(JsString("a string"), SeqCell(JsNumber(1.0), SeqCell(JsBoolean(true), SeqEnd))).print
// res0: String = ["a string", 1.0, true]

ObjectCell(
  "a", SeqCell(JsNumber(1.0), SeqCell(JsNumber(2.0), SeqCell(JsNumber(3.0), SeqEnd))),
  ObjectCell(
    "b", SeqCell(JsString("a"), SeqCell(JsString("b"), SeqCell(JsString("c"), SeqEnd))),
    ObjectCell(
      "c", ObjectCell("doh", JsBoolean(true),
             ObjectCell("ray", JsBoolean(false),
               ObjectCell("me", JsNumber(1.0), ObjectEnd))),
      ObjectEnd
    )
  )
).print
// res1: String = {"a": [1.0, 2.0, 3.0], "b": ["a", "b", "c"], "c": {"doh": true, "ray": false, "me": 1.0}}

4.7.0.3 Music

In the JSON exercise there was a well defined specification to model. In this exercise we want to work on modelling skills given a rather fuzzy specification. The goal is to model music. You can choose to interpret this how you want, making your model as simple or complex as you like. The critical thing is to be able to justify the decisions you made, and to understand the limits of your model.

You might find it easiest to use the BNF notation, introduced in the JSON exercise, to write down your model.

Note ::= pitch:Pitch duration:Duration

Pitch ::= C0 | CSharp0 | D0 | DSharp0 | F0 | FSharp0 | ... | C8 | Rest

Tone ::= C | CSharp | D | DSharp | F | FSharp | ... | B

Octave ::= 0 | 1 | 2 | ... | 8

Pitch ::= tone:Tone octave:Octave

Duration ::= 0 | 1 | 2 | ...

Phrase ::= Sequence | Parallek
Sequence ::= SeqCell phrase:Phrase tail:Sequence
           | SeqEnd

Parallel ::= ParCell phrase:Phrase tail:Parallel
           | ParEnd

Sequence ::= SeqCell note:Note tail:Sequence
           | SeqEnd

Parallel ::= ParCell sequence:Sequence tail:Parallel
           | ParEnd

4.8 Conclusions

In this chapter we have made an extremely important change in our focus, away from language features and towards the programming patterns they support. This continues for the rest of the book.

We have explored two extremely important patterns: algebraic data types and structural recursion. These patterns allow us to go from a mental model of data, to the representation and processing of that data in Scala in an almost entirely mechanical way. Not only in the structure of our code formulaic, and thus easy to comprehend, but the compiler can catch common errors for us which makes development and maintenance easier. These two tools are among the most commonly used in idiomatic functional code, and it is hard to over-emphasize their importance.

In the exercises we developed a few common data structures, but we were limited to storing a fixed type of data, and our code contained a lot of repetition. In the next section we will look at how we can abstract over types and methods, and introduce some important concepts of sequencing operations.

5 Sequencing Computations

In this section we’re going to look at two more language features, generics and functions, and see some abstractions we can build using these features: functors, and monads.

Our starting point is code that we developed in the previous section. We developed IntList, a list of integers, and wrote code like the following:

sealed trait IntList {
  def length: Int =
    this match {
      case End => 0
      case Pair(hd, tl) => 1 + tl.length
    }
  def double: IntList =
    this match {
      case End => End
      case Pair(hd, tl) => Pair(hd * 2, tl.double)
    }
  def product: Int =
    this match {
      case End => 1
      case Pair(hd, tl) => hd * tl.product
    }
  def sum: Int =
    this match {
      case End => 0
      case Pair(hd, tl) => hd + tl.sum
    }
}
case object End extends IntList
final case class Pair(head: Int, tail: IntList) extends IntList

There are two problems with this code. The first is that our list is restricted to storing Ints. The second problem is that here is a lot of repetition. The code has the same general structure, which is unsurprising given we’re using our structural recursion pattern, and it would be nice to reduce the amount of duplication.

We will address both problems in this section. For the former we will use generics to abstract over types, so we can create data that works with user specified types. For the latter we will use functions to abstract over methods, so we can reduce duplication in our code.

As we work with these techniques we’ll see some general patterns emerge. We’ll name and investigate these patterns in more detail at the end of this section.

5.1 Generics

Generic types allow us to abstract over types. There are useful for all sorts of data structures, but commonly encountered in collections so that’s where we’ll start.

5.1.1 Pandora’s Box

Let’s start with a collection that is even simpler than our list—a box that stores a single value. We don’t care what type is stored in the box, but we want to make sure we preserve that type when we get the value out of the box. To do this we use a generic type.

final case class Box[A](value: A)

Box(2)
// res0: Box[Int] = Box(2)

res0.value
// res1: Int = 2

Box("hi") // if we omit the type parameter, scala will infer its value
// res2: Box[String] = Box(hi)

res2.value
// res3: String = hi

The syntax [A] is called a type parameter. We can also add type parameters to methods, which limits the scope of the parameter to the method declaration and body:

def generic[A](in: A): A = in

generic[String]("foo")
// res4: String = foo

generic(1) // again, if we omit the type parameter, scala will infer it
// res5: Int = 1

Type parameters work in a way analogous to method parameters. When we call a method we bind the method’s parameter names to the values given in the method call. For example, when we call generic(1) the name in is bound to the value 1 within the body of generic.

When we call a method or construct a class with a type parameter, the type parameter is bound to the concrete type within the method or class body. So when we call generic(1) the type parameter A is bound to Int in the body of generic.

case class Name[A](...){ ... }
trait Name[A]{ ... }

def name[A](...){ ... }

5.1.2 Generic Algebraic Data Types

We described type parameters as analogous to method parameters, and this analogy continues when extending a trait that has type parameters. Extending a trait, as we do in a sum type, is the type level equivalent of calling a method and we must supply values for any type parameters of the trait we’re extending.

In previous sections we’ve seen sum types like the following:

sealed trait Calculation
final case class Success(result: Double) extends Calculation
final case class Failure(reason: String) extends Calculation

Let’s generalise this so that our result is not restricted to a Double but can be some generic type. In doing so let’s change the name from Calculation to Result as we’re not restricted to numeric calculations anymore. Now our data definition becomes:

A Result of type A is either a Success of type A or a Failure with a String reason. This translates to the following code

sealed trait Result[A]
case class Success[A](result: A) extends Result[A]
case class Failure[A](reason: String) extends Result[A]

Notice that both Success and Failure introduce a type parameter A which is passed to Result when it is extended. Success also has a value of type A, but Failure only introduces A so it can pass it onward to Result. In a later section we’ll introduce variance, giving us a cleaner way to implement this, but for now this is the pattern we’ll use.

sealed trait A[T]
final case class B[T]() extends A[T]
final case class C[T]() extends A[T]

5.1.3 Exercises

5.1.3.1 Generic List

Our IntList type was defined as

sealed trait IntList
case object End extends IntList
final case class Pair(head: Int, tail: IntList) extends IntList

Change the name to LinkedList and make it generic in the type of data stored in the list.

sealed trait LinkedList[A]
final case class Pair[A](head: A, tail: LinkedList[A]) extends LinkedList[A]
final case class End[A]() extends LinkedList[A]

5.1.3.2 Working With Generic Types

There isn’t much we can do with our LinkedList type. Remember that types define the available operations, and with a generic type like A there isn’t a concrete type to define any available operations. (Generic types are made concrete when a class is instantiated, which is too late to make use of the information in the definition of the class.)

However, we can still do some useful things with our LinkedList! Implement length, returning the length of the LinkedList. Some test cases are below.

val example = Pair(1, Pair(2, Pair(3, End())))
assert(example.length == 3)
assert(example.tail.length == 2)
assert(End().length == 0)

sealed trait LinkedList[A] {
  def length: Int =
    this match {
      case Pair(hd, tl) => 1 + tl.length
      case End() => 0
    }
}
final case class Pair[A](head: A, tail: LinkedList[A]) extends LinkedList[A]
final case class End[A]() extends LinkedList[A]

On the JVM we can compare all values for equality. Implement a method contains that determines whether or not a given item is in the list. Ensure your code works with the following test cases:

val example = Pair(1, Pair(2, Pair(3, End())))
assert(example.contains(3) == true)
assert(example.contains(4) == false)
assert(End().contains(0) == false)
// This should not compile
// example.contains("not an Int")

sealed trait LinkedList[A] {
  def contains(item: A): Boolean =
    this match {
      case Pair(hd, tl) =>
        if(hd == item)
          true
        else
          tl.contains(item)
      case End() => false
    }
}

final case class Pair[A](head: A, tail: LinkedList[A]) extends LinkedList[A]
final case class End[A]() extends LinkedList[A]

Implement a method apply that returns the n^th item in the list

Hint: If you need to signal an error in your code (there’s one situation in which you will need to do this), consider throwing an exception. Here is an example:

throw new Exception("Bad things happened")

Ensure your solution works with the following test cases:

val example = Pair(1, Pair(2, Pair(3, End())))
assert(example(0) == 1)
assert(example(1) == 2)
assert(example(2) == 3)
assert(try {
  example(3)
  false
} catch {
  case e: Exception => true
})

sealed trait LinkedList[A] {
  def apply(index: Int): A =
    this match {
      case Pair(hd, tl) =>
        if(index == 0)
          hd
        else
          tl(index - 1)
      case End() =>
        throw new Exception("Attempted to get element from an Empty list")
    }
}
final case class Pair[A](head: A, tail: LinkedList[A]) extends LinkedList[A]
final case class End[A]() extends LinkedList[A]

Throwing an exception isn’t cool. Whenever we throw an exception we lose type safety as there is nothing in the type system that will remind us to deal with the error. It would be much better to return some kind of result that encodes we can succeed or failure. We introduced such a type in this very section.

sealed trait Result[A]
case class Success[A](result: A) extends Result[A]
case class Failure[A](reason: String) extends Result[A]

Change apply so it returns a Result, with a failure case indicating what went wrong. Here are some test cases to help you:

assert(example(0) == Success(1))
assert(example(1) == Success(2))
assert(example(2) == Success(3))
assert(example(3) == Failure("Index out of bounds"))

sealed trait Result[A]
case class Success[A](result: A) extends Result[A]
case class Failure[A](reason: String) extends Result[A]

sealed trait LinkedList[A] {
  def apply(index: Int): Result[A] =
    this match {
      case Pair(hd, tl) =>
        if(index == 0)
          Success(hd)
        else
          tl(index - 1)
      case End() =>
        Failure("Index out of bounds")
    }
}
final case class Pair[A](head: A, tail: LinkedList[A]) extends LinkedList[A]
final case class End[A]() extends LinkedList[A]

5.2 Functions

Functions allow us to abstract over methods, turning methods into values that we can pass around and manipulate within our programs.

Let’s look at three methods we wrote that manipulate IntList.

sealed trait IntList {
  def length: Int =
    this match {
      case End => 0
      case Pair(hd, tl) => 1 + tl.length
    }
  def double: IntList =
    this match {
      case End => End
      case Pair(hd, tl) => Pair(hd * 2, tl.double)
    }
  def product: Int =
    this match {
      case End => 1
      case Pair(hd, tl) => hd * tl.product
    }
  def sum: Int =
    this match {
      case End => 0
      case Pair(hd, tl) => hd + tl.sum
    }
}

case object End extends IntList
case class Pair(hd: Int, tl: IntList) extends IntList

All of these methods have the same general pattern, which is not surprising as they all use structural recursion. It would be nice to be able to remove the duplication.

Let’s start by focusing on the methods that return an Int: length, product, and sum. We want to write a method like

def abstraction(end: Int, f: ???): Int =
  this match {
    case End => end
    case Pair(hd, tl) => f(hd, tl.abstraction(end, f))
  }

I’ve used f to denote some kind of object that does the combination of the head and recursive call for the Pair case. At the moment we don’t know how to write down the type of this value, or how to construct one. However, we can guess from the title of this section that what we want is a function!

A function is like a method: we can call it with parameters and it evaluates to a result. Unlike a method a function is value. We can pass a function to a method or to another function. We can return a function from a method, and so on.

Much earlier in this course we introduced the apply method, which lets us treat objects as functions in a syntactic sense:

object add1 {
  def apply(in: Int) = in + 1
}

add1(2)
// res0: Int = 3

This is a big step towards doing real functional programming in Scala but we’re missing one important component: types.

As we have seen, types allow us to abstract across values. We’ve seen special case functions like Adders, but what we really want is a generalised set of types that allow us to represent computations of any kind.

Enter Scala’s Function types.

5.2.1 Function Types

We write a function type like (A, B) => C where A and B are the types of the parameters and C is the result type. The same pattern generalises from functions of no arguments to an arbitrary number of arguments.

In our example above we want f to be a function that accepts two Ints as parameters and returns an Int. Thus we can write it as (Int, Int) => Int.

(A, B, ...) => C

A => B

5.2.2 Function literals

Scala also gives us a function literal syntax specifically for creating new functions. Here are some example function literals:

val sayHi = () => "Hi!"
// sayHi: () => String = <function0>

sayHi()
// res1: String = Hi!

val add1 = (x: Int) => x + 1
// add1: Int => Int = <function1>

add1(10)
// res2: Int = 11

val sum = (x: Int, y:Int) => x + y
// sum: (Int, Int) => Int = <function2>

sum(10, 20)
// res3: Int = 30

In code where we know the argument types, we can sometimes drop the type annotations and allow Scala to infer them¹⁰. There is no syntax for declaring the result type of a function and it is normally inferred, but if we find ourselves needing to do this we can put a type on the function’s body expression:

(x: Int) => (x + 1): Int

(parameter: type, ...) => expression

5.2.3 Exercises

5.2.3.1 A Better Abstraction

We started developing an abstraction over sum, length, and product which we sketched out as

def abstraction(end: Int, f: ???): Int =
  this match {
    case End => end
    case Pair(hd, tl) => f(hd, tl.abstraction(end, f))
  }

Rename this function to fold, which is the name it is usually known as, and finish the implementation.

sealed trait IntList {
  def fold(end: Int, f: (Int, Int) => Int): Int =
    this match {
      case End => end
      case Pair(hd, tl) => f(hd, tl.fold(end, f))
    }

  // other methods...
}
case object End extends IntList
final case class Pair(head: Int, tail: IntList) extends IntList

Now reimplement sum, length, and product in terms of fold.

sealed trait IntList {
  def fold(end: Int, f: (Int, Int) => Int): Int =
    this match {
      case End => end
      case Pair(hd, tl) => f(hd, tl.fold(end, f))
    }
  def length: Int =
    fold(0, (_, tl) => 1 + tl)
  def product: Int =
    fold(1, (hd, tl) => hd * tl)
  def sum: Int =
    fold(0, (hd, tl) => hd + tl)
}
case object End extends IntList
final case class Pair(head: Int, tail: IntList) extends IntList

Is it more convenient to rewrite methods in terms of fold if they were implemented using pattern matching or polymorphic? What does this tell us about the best use of fold?

Why can’t we write our double method in terms of fold? Is it feasible we could if we made some change to fold?

def double: IntList =
  this match {
    case End => End
    case Pair(hd, tl) => Pair(hd * 2, tl.double)
  }

def fold(end: Int, f: (Int, Int) => Int): Int =
  this match {
    case End => end
    case Pair(hd, tl) => f(hd, tl.fold(end, f))
  }

Implement a generalised version of fold and rewrite double in terms of it.

def fold(end: Int, f: (Int, Int) => Int): Int

def fold[A](end: A, f: (Int, A) => A): A

sealed trait IntList {
  def fold[A](end: A, f: (Int, A) => A): A =
    this match {
      case End => end
      case Pair(hd, tl) => f(hd, tl.fold(end, f))
    }
  def length: Int =
    fold[Int](0, (_, tl) => 1 + tl)
  def product: Int =
    fold[Int](1, (hd, tl) => hd * tl)
  def sum: Int =
    fold[Int](0, (hd, tl) => hd + tl)
  def double: IntList =
    fold[IntList](End, (hd, tl) => Pair(hd * 2, tl))
}
case object End extends IntList
final case class Pair(head: Int, tail: IntList) extends IntList

5.3 Generic Folds for Generic Data

We’ve seen that when we define a class with generic data, we cannot implement very many methods on that class. The user supplies the generic type, and thus we must ask the user to supply functions that work with that type. Nonetheless, there are some common patterns for using generic data, which is what we explore in this section. We have already seen fold in the context of our IntList. Here we will explore fold in more detail, and learn the pattern for implementing fold for any algebraic data type.

5.3.1 Fold

Last time we saw fold we were working with a list of integers. Let’s generalise to a list of a generic type. We’ve already seen all the tools we need. First our data definition, in this instance slightly modified to use the invariant sum type pattern.

sealed trait LinkedList[A]
final case class Pair[A](head: A, tail: LinkedList[A]) extends LinkedList[A]
final case class End[A]() extends LinkedList[A]

The last version of fold that we saw on IntList was

def fold[A](end: A, f: (Int, A) => A): A =
  this match {
    case End => end
    case Pair(hd, tl) => f(hd, tl.fold(end, f))
  }

It’s reasonably straightforward to extend this to LinkedList[A]. We merely have to account for the head element of a Pair being of type A not Int.

sealed trait LinkedList[A] {
  def fold[B](end: B, f: (A, B) => B): B =
    this match {
      case End() => end
      case Pair(hd, tl) => f(hd, tl.fold(end, f))
    }
}
final case class Pair[A](head: A, tail: LinkedList[A]) extends LinkedList[A]
final case class End[A]() extends LinkedList[A]

Fold is just an adaptation of structural recursion where we allow the user to pass in the functions we apply at each case. As structural recursion is the generic pattern for writing any function that transforms an algebraic datatype, fold is the concrete realisation of this generic pattern. That is, fold is the generic transformation or iteration method. Any function you care to write on an algebraic datatype can be written in terms of fold.

Let’s apply the pattern to derive the fold method above. We start with our basic template:

sealed trait LinkedList[A] {
  def fold[B](???): B =
    this match {
      case End() => ???
      case Pair(hd, tl) => ???
    }
}
final case class Pair[A](head: A, tail: LinkedList[A]) extends LinkedList[A]
final case class End[A]() extends LinkedList[A]

This is just the structural recursion template with the addition of a generic type parameter for the return type.

Now we add one function for each of the two classes in LinkedList.

def fold[B](end: ???, pair: ???): B =
  this match {
    case End() => ???
    case Pair(hd, tl) => ???
  }

From the rules for the function types:

• end has no parameters (as End stores no values) and returns B. Thus its type is () => B, which we can optimise to just a value of type B; and
• pair has two parameters, one for the list head and one for the tail. The argument for the head has type A, and the tail is recursive and thus has type B. The final type is therefore (A, B) => B.

Substituting in we get

def fold[B](end: B, pair: (A, B) => B): B =
  this match {
    case End() => end
    case Pair(hd, tl) => pair(hd, tl.fold(end, pair))
  }

5.3.2 Working With Functions

There are a few tricks in Scala for working with functions and methods that accept functions (known as higher-order methods). Here we are going to look at:

1. a compact syntax for writing functions;
2. converting methods to functions; and
3. a way to write higher-order methods that assists type inference.

5.3.2.1 Placeholder syntax

In very simple situations we can write inline functions using an extreme shorthand called placeholder syntax. It looks like this:

((_: Int) * 2)
// res: Int => Int = <function1>

(_: Int) * 2 is expanded by the compiler to (a: Int) => a * 2. It is more idiomatic to use the placeholder syntax only in the cases where the compiler can infer the types. Here are a few more examples:

_ + _     // expands to `(a, b) => a + b`
foo(_)    // expands to `(a) => foo(a)`
foo(_, b) // expands to `(a) => foo(a, b)`
_(foo)    // expands to `(a) => a(foo)`
// and so on...

Placeholder syntax, while wonderfully terse, can be confusing for large expressions and should only be used for very small functions.

5.3.3 Converting methods to functions

Scala contains another feature that is directly relevant to this section—the ability to convert method calls to functions. This is closely related to placeholder syntax—simply follow a method with an underscore:

object Sum {
  def sum(x: Int, y: Int) = x + y
}

Sum.sum
// <console>:23: error: missing argument list for method sum in object Sum
// Unapplied methods are only converted to functions when a function type is expected.
// You can make this conversion explicit by writing `sum _` or `sum(_,_)` instead of `sum`.
//        Sum.sum
//            ^

(Sum.sum _)
// res1: (Int, Int) => Int = <function2>

In situations where Scala can infer that we need a function, we can even drop the underscore and simply write the method name—the compiler will promote the method to a function automatically:

object MathStuff {
  def add1(num: Int) = num + 1
}

Counter(2).adjust(MathStuff.add1)
// res2: Counter = Counter(3)

5.3.3.1 Multiple Parameter Lists

Methods in Scala can actually have multiple parameter lists. Such methods work just like normal methods, except we must bracket each parameter list separately.

def example(x: Int)(y: Int) = x + y
// example: (x: Int)(y: Int)Int

example(1)(2)
// res3: Int = 3

Multiple parameter lists have two relevant uses: they look nicer when defining functions inline and they assist with type inference.

The former is the ability to write functions that look like code blocks. For example, if we define fold as

def fold[B](end: B)(pair: (A, B) => B): B =
  this match {
    case End() => end
    case Pair(hd, tl) => pair(hd, tl.fold(end, pair))
  }

then we can call it as

fold(0){ (total, elt) => total + elt }

which is a bit easier to read than

fold(0, (total, elt) => total + elt)

More important is the use of multiple parameter lists to ease type inference. Scala’s type inference algorithm cannot use a type inferred for one parameter for another parameter in the same list. For example, given fold with a signature like

def fold[B](end: B, pair: (A, B) => B): B

if Scala infers B for end it cannot then use this inferred type for the B in pair, so we must often write a type declaration on pair. However, Scala can use types inferred for one parameter list in another parameter list. So if we write fold as

def fold[B](end: B)(pair: (A, B) => B): B

then inferring B from end (which is usually easy) allows B to be used when inferring the type pair. This means fewer type declarations and a smoother development process.

5.3.4 Exercises

5.3.4.1 Tree

A binary tree can be defined as follows:

A Tree of type A is a Node with a left and right Tree or a Leaf with an element of type A.

Implement this algebraic data type along with a fold method.

sealed trait Tree[A] {
  def fold[B](node: (B, B) => B, leaf: A => B): B
}
final case class Node[A](left: Tree[A], right: Tree[A]) extends Tree[A] {
  def fold[B](node: (B, B) => B, leaf: A => B): B =
    node(left.fold(node, leaf), right.fold(node, leaf))
}
final case class Leaf[A](value: A) extends Tree[A] {
  def fold[B](node: (B, B) => B, leaf: A => B): B =
    leaf(value)
}

Using fold convert the following Tree to a String

val tree: Tree[String] =
  Node(Node(Leaf("To"), Leaf("iterate")),
       Node(Node(Leaf("is"), Leaf("human,")),
            Node(Leaf("to"), Node(Leaf("recurse"), Leaf("divine")))))

Remember you can append Strings using the + method.

tree.fold[String]((a, b) => a + " " + b, str => str)

5.4 Modelling Data with Generic Types

In this section we’ll see the additional power the generic types give us when modelling data. We see that with generic types we can implement generic sum and product types, and also model some other useful abstractions such as optional values.

5.4.1 Generic Product Types

Let’s look at using generics to model a product type. Consider a method that returns two values—for example, an Int and a String, or a Boolean and a Double:

def intAndString: ??? = // ...

def booleanAndDouble: ??? = // ...

The question is what do we use as the return types? We could use a regular class without any type parameters, with our usual algebraic data type patterns, but then we would have to implement one version of the class for each combination of return types:

case class IntAndString(intValue: Int, stringValue: String)

def intAndString: IntAndString = // ...

case class BooleanAndDouble(booleanValue: Boolean, doubleValue: Double)

def booleanAndDouble: BooleanAndDouble = // ...

The answer is to use generics to create a product type—for example a Pair—that contains the relevant data for both return types:

def intAndString: Pair[Int, String] = // ...

def booleanAndDouble: Pair[Boolean, Double] = // ...

Generics provide a different approach to defining product types— one that relies on aggregation as opposed to inheritance.

5.4.1.1 Exercise: Pairs

Implement the Pair class from above. It should store two values—one and two—and be generic in both arguments. Example usage:

val pair = Pair[String, Int]("hi", 2)
// pair: Pair[String,Int] = Pair(hi,2)

pair.one
// res0: String = hi

pair.two
// res1: Int = 2

case class Pair[A, B](one: A, two: B)

val pair = Pair("hi", 2)
// pair: Pair[String,Int] = Pair(hi,2)

5.4.2 Tuples

A tuple is the generalisation of a pair to more terms. Scala includes built-in generic tuple types with up to 22 elements, along with special syntax for creating them. With these classes we can represent any kind of this and that relationship between almost any number of terms.

The classes are called Tuple1[A] through to Tuple22[A, B, C, ...] but they can also be written in the sugared¹¹ form (A, B, C, ...). For example:

Tuple2("hi", 1) // unsugared syntax
// res2: (String, Int) = (hi,1)

("hi", 1) // sugared syntax
// res3: (String, Int) = (hi,1)

("hi", 1, true)
// res4: (String, Int, Boolean) = (hi,1,true)

We can define methods that accept tuples as parameters using the same syntax:

def tuplized[A, B](in: (A, B)) = in._1
// tuplized: [A, B](in: (A, B))A

tuplized(("a", 1))
// res5: String = a

We can also pattern match on tuples as follows:

(1, "a") match {
  case (a, b) => a + b
}
// res6: String = 1a

Although pattern matching is the natural way to deconstruct a tuple, each class also has a complement of fields named _1, _2 and so on:

val x = (1, "b", true)
// x: (Int, String, Boolean) = (1,b,true)

x._1
// res7: Int = 1

x._3
// res8: Boolean = true

5.4.3 Generic Sum Types

Now let’s look at using generics to model a sum type. Again, we have previously implemented this using our algebraic data type pattern, factoring out the common aspects into a supertype. Generics allow us to abstract over this pattern, providing a … well … generic implementation.

Consider a method that, depending on the value of its parameters, returns one of two types:

def intOrString(input: Boolean) =
  if(input == true) 123 else "abc"
// intOrString: (input: Boolean)Any

We can’t simply write this method as shown above because the compiler infers the result type as Any. Instead we have to introduce a new type to explicitly represent the disjunction:

def intOrString(input: Boolean): Sum[Int, String] =
  if(input == true) {
    Left[Int, String](123)
  } else {
    Right[Int, String]("abc")
  }
// intOrString: (input: Boolean)sum.Sum[Int,String]

How do we implement Sum? We just have to use the patterns we’ve already seen, with the addition of generic types.

5.4.3.1 Exercise: Generic Sum Type

Implement a trait Sum[A, B] with two subtypes Left and Right. Create type parameters so that Left and Right can wrap up values of two different types.

Hint: you will need to put both type parameters on all three types. Example usage:

Left[Int, String](1).value
// res9: Int = 1

Right[Int, String]("foo").value
// res10: String = foo

val sum: Sum[Int, String] = Right("foo")
// sum: sum.Sum[Int,String] = Right(foo)

sum match {
  case Left(x) => x.toString
  case Right(x) => x
}
// res11: String = foo

sealed trait Sum[A, B]
final case class Left[A, B](value: A) extends Sum[A, B]
final case class Right[A, B](value: B) extends Sum[A, B]

5.4.4 Generic Optional Values

Many expressions may sometimes produce a value and sometimes not. For example, when we look up an element in a hash table (associative array) by a key, there may not be a value there. If we’re talking to a web service, that service may be down and not reply to us. If we’re looking for a file, that file may have been deleted. There are a number of ways to model this situation of an optional value. We could throw an exception, or we could return null when a value is not available. The disadvantage of both these methods is they don’t encode any information in the type system.

We generally want to write robust programs, and in Scala we try to utilise the type system to encode properties we want our programs to maintain. One common property is “correctly handle errors”. If we can encode an optional value in the type system, the compiler will force us to consider the case where a value is not available, thus increasing the robustness of our code.

5.4.4.1 Exercise: Maybe that Was a Mistake

Create a generic trait called Maybe of a generic type A with two subtypes, Full containing an A, and Empty containing no value. Example usage:

val perhaps: Maybe[Int] = Empty[Int]

val perhaps: Maybe[Int] = Full(1)

sealed trait Maybe[A]
final case class Full[A](value: A) extends Maybe[A]
final case class Empty[A]() extends Maybe[A]