Scala 2.12.0 リリースノート

昨日リリースされたばかりの Scala 2.12.0 のリリースノートを翻訳しました。 Lightbend 社 Scala チームのコンパイラ魂を感じ取れる、マニアな内容になっています。

Scala 2.12.0 がリリースされました!

Scala 2.12 コンパイラは Java 8 から使えるようになった新しい VM 機能を利用するために、完全なオーバーホールが行われた。

• トレイトは、デフォルトメソッド付きのインターフェイスに直にコンパイルされる。これはバイナリ互換性と Java との相互運用性を向上させる。
• Scala と Java 8 の相互運用 (interop) という点では、関数を受け取るメソッドが両方向からもラムダ構文で呼び出せるようになったので関数型なコードにおいても改善した。Scala 標準ライブラリの FunctionN クラス群は、Single Abstract Method (SAM) 型となり、全ての SAM型は、型検査からコード生成におけるまで統一的に取り扱われる (クラスファイルは生成されず、代わりに invokedynamic が用いられる)。

gigahorse-github 0.1.0

gigahorse-github 0.1.0 をリリースした。これは、Github API v3 のための Gigahorse プラグインだ。

Gigahorse 0.1.0

更新: Gigahorse 0.1.1　を使ってください。

Gigahorse 0.1.0 をリリースした。これは Scala のための HTTP クライアントで、内部にAsync Http Client を使っている。詳しくは Gigahorse ドキュメントを書いたので、それを参照してほしい。ライブラリがどういう感じなのかを例でみるとこんな感じだ。

scala> import gigahorse._
scala> import scala.concurrent._, duration._
scala> Gigahorse.withHttp(Gigahorse.config) { http =>
         val r = Gigahorse.url("http://api.duckduckgo.com").get.
           addQueryString(
             "q" -> "1 + 1",
             "format" -> "json"
           )
         val f = http.run(r, Gigahorse.asString andThen {_.take(60)})
         Await.result(f, 120.seconds)
       }

registry and reference パターン

ここ最近考えている「パターン」があって、オブジェクトを永続化/シリアライゼーションするみたいな状況で出てくる。

問題提起として、以下のような case class を考えてみてほしい:

scala> case class User(name: String, parents: List[User])
defined class User

scala> val alice = User("Alice", Nil)
alice: User = User(Alice,List())

scala> val bob = User("Bob", alice :: Nil)
bob: User = User(Bob,List(User(Alice,List())))

scala> val charles = User("Charles", bob :: Nil)
charles: User = User(Charles,List(User(Bob,List(User(Alice,List())))))

scala> val users = List(alice, bob, charles)
users: List[User] = List(User(Alice,List()), User(Bob,List(User(Alice,List()))),
  User(Charles,List(User(Bob,List(User(Alice,List()))))))

注目してほしいのは parents という他のユーザを参照するリストを保持してることだ。 次に、users リストを JSON に変換したいとする。

[{ "name": "Alice", "parents": [] },
{ "name": "Bob",
  "parents": [{ "name": "Alice", "parents": [] }] },
{ "name": "Charles",
  "parents": [{ "name": "Bob", "parents": [{ "name": "Alice", "parents": [] }] }] }]

この方法だと複数の問題点がある。まず、JSON の表記として効率が悪いし JSON データとして期待される自然な感じではないことだ。次に、これを case class に変換しなおしたときにオブジェクトのグラフごとインスタンス化する必要があって、それも非効率だし、望ましくない状況が多いと思う。

データが関数値などを保持しているとさらに厄介なことになってくる。

registry and reference パターン

この対策として考えているものを僕は registry and reference パターンと呼んでいる。基本的な考えとしては、予め 3人のユーザを registry (登記所) に登録して、JSON は以下のような内容で伝達する:

["Alice", "Bob", "Charles"]

ググってみると Martin Fowler 先生も Registry パターンと呼んでいるみたいだ。彼のモデルだと Registry は以下の 2つのメソッドを含む:

sjson-new とアズカバンの囚人

本稿は sjson-new に関する第3部だ。パート1、パート2も是非読んでみてほしい。

sbt のコード内にはデータ永続化が数百メガバイトのオーダーに達している部分がいくつかあって、特にマシンに SSD が積まれていない場合は性能ボトルネックになる疑いがあるんじゃないかと思っている。 当然、最初に飛びついたのは Google Protocol Buffers のエンコーディングを参考に独自のバイナリフォーマットを実装することだった。

sbt-jmh を用いたマイクロベンチマーク

僕がまずやるべきだったのは、ベンチマークを取ることだ。@ktosopl (Konrad Malawski)君の sbt-jmh を使うとマイクロベンチマークは簡単に作ることができる。ビルドにプラグインを入れて、JmhPlugin を有効化したサブプロジェクトを定義するだけだ。

lazy val benchmark = (project in file("benchmark")).
  dependsOn(supportSpray). // add other subprojects you want to test
  enablePlugins(JmhPlugin).
  settings(
    libraryDependencies ++= Seq(jawnSpray, lm),
    // sbt-jmh forks the run, so you would need these
    javaOptions in (Jmh, run) ++= Seq("-Xmx1G", "-Dfile.encoding=UTF8"),
    publish := {},
    publishLocal := {},
    PgpKeys.publishSigned := {}
  )

一つ注意が必要なのは sbt-jmh はフォークした run を使っているので、javaOptions in (Jmh, run) の設定が必要なことだ。

あとは例にならってベンチマークを定義していくだけだ。僕は Jawn の真似をして abstract class にしてみた。

sjson-new と LList を用いたカスタムコーデック

2ヶ月ぐらい前に sjson-new について書いた。週末にまたちょっといじってみたので、ここに報告する。 前回は Scala エコシステムにおける JSON ライブラリの家系をたどって、複数バックエンドに対応し、かつ型クラスベースの JSON コーデックライブラリという概念を導入した。課題は、カスタムコーデックを簡単に定義できるようにする必要があるということだった。

私家版 shapeless

4月に書いたのと先週までの間に flatMap(Oslo) 2016 と Scala Days New York 2016 という 2つのカンファレンスがあった。残念ながら、僕は flatMap の方には行けなかったけども、Daniel Spiewak さんの “Roll Your Own Shapeless” (「私家版 Shapeless のすゝめ」) というトークを New York で聞けた。flatMap 版の方が完全版でそれは vimeo にも出てるので、是非チェックしてみてほしい。

sbt の内部では、sbinary を用いたキャッシングに HList が用いられてたりする:

implicit def mavenCacheToHL = (m: MavenCache) => m.name :*: m.rootFile.getAbsolutePath :*: HNil
implicit def mavenRToHL = (m: MavenRepository) => m.name :*: m.root :*: HNil
...

そういう影響もあって、HList とか Shapeless の LabelledGeneric みたいなのがあれば JSON object を表す中間値としていいのではないかと思っていたので、Daniel のトークには最後に背中を押してもらった気がする。

本稿では、HList の目的を特化した LList というものを紹介する。

LList

sjson-new には LList というデータ型があって、これは labelled heterogeneous list、ラベル付された多型リストだ。 標準ライブラリについてくる List[A] は、A という同じ型しか格納することができない。標準の List[A] と違って、LList はセルごとに異なる型の値を格納でき、またラベルも格納することができる。このため、LList はそれぞれ独自の型を持つ。REPL で見てみよう:

foundweekends

週末に趣味プログラミングをする人のための Github organization として foundweekends を作った。参加したい人は twitter か Gitter で声をかけてください。

当面の活動は @n8han から conscript、giter8、pamflet を引き継ぐことだ。

sjson-new

背景

ソフトウェアプロジェクトを考える面白い方法の一つとして、文学的な解析があると思う。つまり、実際のコードの字面を追うだけじゃなくて、誰が、いつ、何故 (どういった問題を解決するために) どのようにして (何の影響を受けて) 書いたのかを考察することだ。そういった意味では、Scala エコシステムにおいては JSON ライブラリほど豊かなジャンルは他に無いのではないだろうか。

2008年12月に Programming in Scala の初版が出て、JSON はパーサ・コンビネータの一例として出てきて、JSON パーサが 10行ぐらいのコードで書けることを示した:

import scala.util.parsing.combinator._
class JSON extends JavaTokenParsers {
  def value : Parser[Any] = obj | arr |
                            stringLiteral |
                            floatingPointNumber |
                            "null" | "true" | "false"
  def obj   : Parser[Any] = "{"~repsep(member, ",")~"}"
  def arr   : Parser[Any] = "["~repsep(value, ",")~"]"
  def member: Parser[Any] = stringLiteral~":"~value
}

同年の一ヶ月前に Real World Haskell という本も出てて、これも JSON ライブラリを例をして使った (Chapter 5. Writing a library: working with JSON data)。これは JSON データが JValue と呼ばれる代数的データ型によって記述できることを解説した:

この考え方は僕たちのエコシステムに大きな影響を与えた。

sbt server リブート

これは先日書いた sbt 1.0 ロードマップの続編だ。この記事では sbt server の新しい実装を紹介する。感想やコメントがあれば sbt-dev mailing list にお願いします。

sbt server の動機は IDE との統合の改善だ。

ビルドは、巨大で、可変で、共有された、状態のデバイスだ。ディスクのことだよ! ビルドはディスク上で動作するのもであって、ディスクから逃れることはできない。

– Josh Suereth、The road to sbt 1.0 is paved with server より

マシンに積んであるディスクは根本的にステートフルなものであり、sbt がタスクを並行実行できるのもそれが作用に関する完全なコントロールを持っていることが大前提になっている。同じビルドに対して sbt と IDE を同時に実行していたり、複数の sbt インスタンスを実行している場合は、sbt はビルドの状態に関して一切保証することができない。

sbt 1.0 ロードマップ

sbt 1.0 にに関して TL上とかで議論があったので、叩き台としてこれを書くことにした。何かをちゃんとリリースできるように仕切り直しするための中期的なミッション・ステートメントだと思ってほしい。sbt-dev mailing list にて今後も議論を続けていきたい。

タイミング

いつ sbt 1.0 をリリースできるかという予定はまだ見当が付いていない。 sbt 1.0 の最大の機能はコードの再組織で、それは既に進んでいる: http://www.scala-sbt.org/0.13/docs/Modularization.html

sbt/io、 sbt/util、 sbt/librarymanagement、 sbt/incrementalcompiler といったモジュールがある。実装という観点からするとインクリメンタルコンパイラが sbt の中で一番複雑な部分だと思うので、まずはそれをモジュール化することを目標としてきた。全部のモジュールの API が安定したときが、sbt 本体にも 1.0 を付けれる時になる。

モジュール化の動機

sbt/sbt の現在のコードは、ビルドユーザやプラグイン作者に内部を晒しすぎている。これによってとっつきづらいコードになっている。さらに、バイナリ互換性を保つのも難しくなっている。 モジュール化の目標はどこまでが public な API でどこからが private な実装なのかの境界をハッキリさせることだ。

あと、これらのモジュールは今まで使ってたような Ivy リポジトリじゃなくて Maven Central に乗せる。

sbt/zinc

新しいインクリメンタルコンパイラは完全に name hashing に移行する。name hashing はしばらく前 (sbt 0.13.6) からデフォルトでオンになっている。それだけじゃなくて、クラスベースの name hashing を使う予定で、これは性能改善が期待されている。

Java バージョン

sbt 0.13 は JDK 6 の上に書かれている。sbt 1.0 は JDK 8 ベースだ。

sbt-archetype

sbt-archetype は Jim Powers が提案するコンセプトで、sbt に Activator みたいに new コマンドを付けるというものだ。templateResolvers セッティングみたいなバックエンド機構をつけて、テンプレートのソースは設定で Activator Template、Github、private repository など変えれるようにしたい。

ライフスタイルとしての ScalaMatsuri

僕にとって ScalaMatsuri とはライフスタイルのようなものだ (他の 27名近くいるオーガナイザーも同じように思っているんじゃないだろうか)。確かに、近日東京で 550名を動員したカンファレンスがあって、それは成功に終わった。しかし、オーガナイザーは 2015年の 2/28 からかれこれ 11ヶ月間準備してきた。僕が関わったのは一部でしかないけども、ScalaMatsuri 2016 はこれまでで一番関わりの深いカンファレンスになったと思う。この何ヶ月の間 Slack、Hangout たまには対面で、さまざまな議論を重ねてきた。面白かったのは、一緒にアイディアを出し合ってそれが実現されるのをみることだったと思う。僕が奇抜なアイディアを出して、その詳細を誰かが実行してくれることもあれば、他の人が始めたことを元に僕が現場の作業をすることもあった。

色々言いたいことは「グローバルな技術カンファレンス」と「日本のコミュニティの交流」の両立でも書いちゃったので、かぶる部分もあると思う。

2015年3月

2015年の 3/16 の段階で既に ScalaMatsuri 2015 の準備は回り始めていた。何故覚えているかというとそれは麻植さん (@oe_uia) が法被を来て Scala Days San Francisco に登場したからだ。カンファレンスと一緒にスキーやスノボもできるようにということで、あの場の雰囲気で 2016年の 1月にずらそうというアイディアが生まれた。

ホテル街は Scala Days の会場から少し歩く所にあってその帰り道で麻植さんと CFP を公開して固定費で旅費サポートを付けようという話をしたのを覚えている。これは少なくとも 2014年 (カンファレンスでのユニバーサル・アクセスへ向けて) ぐらいから考えてるアイディアで、非公開で誰かを招待してその人達の旅費を払うのに比べていくつもの利点があると思っている。カンファレンスを延期したことで以前より長い準備期間を得ることができたので、やってみる見込みがたった。

Github issue all the things

今回から以前のカンファレンス準備で使われていた Trello や co-meeting から Slack と Github issue の組み合わせに乗り換えた。 両者はそれぞれを補完する関係にあって、よい決断だったと思う。ラベルを使って issue を担当チームに割り当てるという運用をしていて、これもうまくいっていたと思う。

小さいタスクが大量にできてきて Github issue で困ったのは、特定のタスクが今どういう状況にあるのかを把握するのが難しいということだった。何かが起こるのを待っているのか、もしくは誰かが作業中なのか、といったことだ。issue の subject に括弧書きでミニ・ステータスを書くということをやってみたけども、翻訳タスクなど事前に明確にステップが定義されているタスク類に関してはこの括弧書き方式はうまくいったと思う。

「和」を想起させる web サイト

準備の早期の段階ではオーガナイザーは月一ぐらいのペースで会っていたと思う。僕を含め東京に住んでない人もいるので、ミーティングは Google Hangout でストリームされて、Hangout もしくは Slack 経由で議論に参加できた。

「グローバルな技術カンファレンス」と「日本のコミュニティの交流」の両立

ScalaMatsuri 運営ブログに「グローバルな技術カンファレンス」と「日本のコミュニティの交流」の両立を書きました。

-Yno-lub を用いた Scala の厳格化

Scala は柔軟なプログラミング言語なので、個人的な Good Parts のような言語のサブセット、もしくは主義主張のあるスタイルガイドを作ることは有用だ。

セットアップ

-Yno-lub を試してみたい人は、以下を project/ynolub.sbt に書いて sbt プラグインを引っ張ってくる:

addSbtPlugin("com.eed3si9n" % "sbt-ynolub" % "0.2.0")

lub

Scala の型推論が型 A と型 B を統合するとき、それらの <:< に関する lub (least upper bounds, 最小上界) を計算する。この過程を lubbing と呼ぶこともある。具体例で説明する:

scala> if (true) Some(1) else None
res0: Option[Int] = Some(1)

scala> if (true) List(1) else Nil
res1: List[Int] = List(1)

ここ数年考えているのは、少なくとも今ある形での lubbing は有益ではないのではないか、ということだ。2013年にもこんなことを言っている:

are non-imported implicits and lubing useful in #scala? Map to List[Tuple2], Int to Double, Foo and Bar to Any. I'd rather see errors

— eugene yokota (@eed3si9n) November 26, 2013

非import の implicit や lubbing は #scala の役に立つものだろうか? Map から List[Tuple2]、Int から Double、 Foo と Bar から Any。むしろ僕はそれらがエラーになってほしい。

Read More…

猫番: 1日目

猫番という新しいシリーズを始めた。(これは最初から Pamflet で書いている)

Cats は Scala のための関数型プログラミングのライブラリで、これは僕がそれを使ってみた記録だ。 Cats は、現在開発中で未だ実験段階にある。

Java バージョンの切り替え

最近 Mac と Ubuntu、それから Java 6 と Java 7 を行ったり来たりしてる。 Java の切り替え方を統一したいので、ここにメモしておく。

追記: jEnv という便利なものを Yoshida-san に教えてもらったので、それを使ったほうがいいかも。

Zshrc

OS によるシェルスクリプトの切り替えはこんなふうにやってる:

## basic
[ -f $HOME/dotfiles/zshrc.basic ] && source $HOME/dotfiles/zshrc.basic
 
## aliases
[ -f $HOME/dotfiles/zshrc.alias ] && source $HOME/dotfiles/zshrc.alias
 
case "${OSTYPE}" in
# MacOSX
darwin*)
  [ -f $HOME/dotfiles/zshrc.osx ] && source $HOME/dotfiles/zshrc.osx
  ;;
# Linux
linux*)
  [ -f $HOME/dotfiles/zshrc.linux ] && source $HOME/dotfiles/zshrc.linux
  ;;
esac
 
## color
[ -f $HOME/dotfiles/zshrc.color ] && source $HOME/dotfiles/zshrc.color

環境変数

zshrc.osx と zshrc.linux のそれぞれに Java 6、7、8用の環境変数を定義する。まずは Mac:

Scala Pickling 0.10.0

pickling 0.10.0 として implicit.ly に投稿したものを訳しました。 最近コミッター権をもらいましたが、Pickling の 90% 以上は Eugene Burmako、Heather Miller、Philipp Haller によって書かれています。

Scala Pickling は、Scala のための自動シリアライゼーション・フレームワークで、0.10.0 が初の安定版となる。Pickling は高速で、ボイラープレート (冗長なお決まりコード) 無しで書くことができ、ユーザ側で (バイナリや JSON などの) シリアライゼーション・フォーマットを簡単に差し替えることができる。また、0.10.x シリーズ中はバイナリ互換性とフォーマットの互換性の両方を保つ予定だ。

Pickling を短くまとめると

ある任意の値、例えば　Person("foo", 20) を pickle する (シリアライズ化を保存食に喩えて、漬物に「漬ける」と言う) とき、以下の 2つのものが必要になる:

1. 与えられた型 Person の pickler コンビネータ
2. pickle フォーマット

Pickler[A] は A をエントリー、フィールド、コレクションといった抽象的なものに分解することを担当する。プリミティブな pickler を合成して複合的な pickler を作ることができるため、コンビネータと呼ばれている。一方 PickleFormat はフィールドなどの抽象的な概念をバイナリやテキストといった形に具現化する。

Defaults モード

以下は基本形である Defaults モードの使用例だ。

scala> import scala.pickling.Defaults._, scala.pickling.json._
scala> case class Person(name: String, age: Int)

scala> val pkl = Person("foo", 20).pickle
pkl: pickling.json.pickleFormat.PickleType =
JSONPickle({
  "$type": "Person",
  "name": "foo",
  "age": 20
})

scala> val person = pkl.unpickle[Person]
person: Person = Person(foo,20)

この Defaults モードは、プリミティブ pickler 群から Pickler[Person] をコンパイル時に自動的に導出する! コードが静的に生成されるため、文字列の操作などもインライン化して高速化している。(同じくスキーマを使わない Java serialization や Kryo に比べても速い)

モナドはフラクタルだ

Uppsala から帰ってくる途中、何となく思い出したのは同僚とのモナドの直観についての会話で、僕は酷い説明をした気がする。色々考えているうちに、ちょっとひらめきがあった。

モナドはフラクタルだ

上のフラクタルはシェルピンスキーの三角形と呼ばれるもので、僕がそらで描ける唯一のフラクタルだ。フラクタルとは自己相似的な構造で、上の三角形のように部分が全体の相似となっている (この場合は、親の三角形の半分のスケールの相似)。

モナドはフラクタルだ。モナディックなデータ構造があるとき、その値のいくつかを合成して同じデータ構造の新しい値を形成することができる。これがモナドがプログラミングに有用である理由であり、また多くの場面で登場する理由だ。

具体例で説明する:

scala> List(List(1), List(2, 3), List(4))
res0: List[List[Int]] = List(List(1), List(2, 3), List(4))

カンファレンスでのユニバーサル・アクセスへ向けて

2日間の #ScalaMatsuri は盛況に終わった。だけど、来年へ向けて色々課題もあるので、それを自分なりに書き出してみる。題の通り、僕達の次の目標とするべきものはユニバーサル・アクセスだと考えている。Scala 言語においては、統一アクセスの原則 (universal access principle) と言えば、メソッドとフィールドの両方が外側から見ると別けへだて無くアクセスできることを指す。

この文脈でのユニバーサル・アクセスは、様々なグループの人にとっても包括的 (inclusive) なカンファレンスという意味で使っている。具体的には:

• 女性/男性/ヘテロ/LGBT のプログラマ
• 日本語/英語話者
• 初心者と上級者
• ポスドクなどの研究者
• 日本以外のアジア諸国からの人

など。

テクノロジー界における女性問題、及びその他のジェンダー問題

去年は女性によるセッション数はゼロ。今年は、マクロに関してのセッションが一つと、FuRyu さんのスポンサー LT が一本あった。これは良い傾向だと思うけど、僕としては、女性の人による Scala コミュニティ一般への参加、勉強会などへの出席、そして ScalaMatsuri のようなカンファレンスへの出席をもっと応援したいと思う。男性側としてできることの一つに、もし勉強会に参加してくれた女性の方がいたら、変な挙動を取らずに普通のハッカーの一人として接することがあると思う。

Scala Days、NE Scala、そして PNW Scala に倣って、今年の ScalaMatsuri では Geek Feminism Wiki/Ada Initiative を原案とする行動規範を採用した。この行動規範は、全員にハラスメント・フリーの経験を提供することを約束し、特に「全てのコミュニケーションは、技術的な発表の場にふさわしいものであるべき」ことを求める。今後、正式なハラスメント報告方法の確立などを含む、ポリシーの実装をはっきりさせる必要があるが、公的にこのようなガイドラインを採用できたことで、より inclusive なカンファレンスになっていくと考えている。

言語の壁

Scala がよく使われているその他の欧米諸国に比べて、日本の英語スキルは特にリスニングとスピーキングで遅れている。ScalaMatsuri の運営側としては、カンファレンスをより尖ったものにして、Scala コミュニティからより多くの英語話者を惹きつけることを目標の一つとしている。それに沿って、招待講演者の旅費を出したり、テキスト翻訳を提供したり、一般的に英語話者が来ても楽しめるように歓迎するようにしている。今年は、日本語話者でも英語で発表する人も出てきた。

このような努力は、Scala には興味があるが英語は苦手という多くのカンファレンス参加者にとって利害関係の衝突となる。リアルタイムで提供される有志によるテキスト翻訳は、無いよりはいいかもしれないけど、往々にして不十分である。解決方法として検討するべきはプロの通訳を雇うことだ。これは YAPC::Asia などではうまくいったらしい。さらに、2つの別路線 (track) を作って、それぞれ英語での発表と日本語での発表を行うべきだ。

初心者と上級者

Matsuri は祭という意味で、テーマも “enjoy Scala” だった。前から Scala をやってきてるユーザには確かに楽しいカンファレンスだったかもしれないが、僕のものも含め多くのトークは初心者を置いてきぼりにしたものとなった。この回避方法となり得るかもしれないのが、英語路線と日本語路線の区別の他に、NE Scala のようにセッションを参加者の投票で決めてもらうことだ。（通訳付きで）英語のセッションでも聞いてみたい人と上級者、逆に日本語にして欲しい人と初心者に相関性があると仮定すると、それぞれの路線が、投票によって聴衆が聞きたい適切なレベルに補正されるのではないだろうか。

ポスドクとアジア諸国からの参加者

1日目のレポートに書いたとおり、宋 剛秀さんの発表は唯一学術的な方面からのものだったけど、独自で面白いものだった。アメリカやヨーロッパからのロックスター的な登壇者を観るのも面白いけども、日本から宋さんのようなポスドクの研究者や、はたまた近隣のアジア諸国である、インド、中国、韓国、台湾、シンガポールなどから呼んでみるのも面白いのではないだろうか。英語路線を設けることで、日本語の心配はいらなくなると思う。実装する方法の一つとしては、CFP をもっと比較的長く取って、例えば最大 $1500 までで旅費のサポートをすると宣伝すればいいと思う。投票後には、旅費予算から差し引いていって、票の多い順に可能な限りの人を招待すればいい。

全ての受け皿としてのアンカンファレンス

もし英語路線か日本語路線のどちらかの競争率が高くなっても、今後はアンカンファレンスを受け皿として機能させることができる。今回で多くの人が直接アンカンファレンスが行われる様子を見たので、今後はより多くの議論や準備済みのトークが増えることを期待していう。来年からはホワイトボードを廃止して、当日の朝に Google docs に直接全てのアンカンファレンスのアイディアをファシリテータ名と共に書く方向に変えていくべきだと思う。狙いはあまり人気が無いセッションでも部屋が空いていれば、ちゃんとセッションを設けることにある。

ScalaMatsuri 1日目

日本での Scala カンファレンスも今年で二年目だ。今年は ScalaMatsuri と名前を変えて仕切り直し。300枚のチケットは売り切れ、招待講演者やスポンサー招待枠などを入れたら当日はもっといたかもしれない。アメーバブログやオンライン広告サービスなどを事業とする CyberAgent さんのオフィスを会場としてお借りした。

1日目のトップバッターは小田好先生こと Martin Odersky 先生 (@ordersky) の「Scala 進化論」。多くの人が小田好先生の講演を楽しみにしていたので、朝から満員に近かったと思う。僕が出席したセッションは、拙作の closed-captioning を使って和英、英和のテキスト翻訳を打ち込むのに忙しかった。一日目翻訳チームの他のメンバーは、@cbirchall、 @cdepillabout、 @okapies、 @oe_uia。

次に僕が「sbt、傾向と対策」を日本語で話した。mkdir helloworld から始めて、sbt の最初のステップから、continuous testing までの流れのデモから始めた。次に、基礎コンセプト、0.13.6 で入る新機能である HTTPS デフォルト、consolidated resolution、eviction warning を紹介して、最後に「サーバとしての sbt」とさらなる性能の改善という将来の展望でシメた。LinkedIn社のプレスチームから、LinkedIn が sbt の性能改善の仕事をスポンサーしてもらってることを話してもいい許可をもらってきたので、今回機能改善に関して公の場でお礼できたのは良かったと思う。

Activator と sbt に関して質問があった。Activator の 3つの用例ということで以下のように回答した:

• トレーニング・セッションなどにおける USBドライブなどによる Typesafe スタックのオフライン配布
• 新ユーザの out-of-the-box エクスペリエンス (箱を開けてすぐ遊べること) の改善
• ユーザがコードを打ち込みながら使えるチュートリアルをホストするプラットフォーム

sbt サーバに関しては、IntelliJ などの他のツールとの連携、と将来的な remote compilation などの可能性ができること両方について好反応を得た。

Jon Pretty (@propensive) さんの ‘Fifty Rapture One-Liners in Forty Minutes’ という講演。リソースの読み書きを抽象化することに焦点を絞ったライブラリみたいで、オンラインから色々読み込んで、生の状態の読み込み (slurp) や case class への落とし込みをするみたいだ。enrich-my-library、マクロ、dynamics などユーザ・フレンドリーな Json 処理のために言語のトリックを多用している。バックエンドの json ライブラリが選べるようになっているのは好印象。

Vim メモ

個人的には SublimeText で特に困っていないし、メインのエディタとしてしばらく使ってきた。だけど、コマンドラインから使えるエディタにも少しは興味があるし、色んな人がネットワーク上から使えるから便利ということを言っている。X を転送したり、他の方法でリモートインすれば Sublime を使えるんじゃないかとも思うが、一応試してみよう。

この Vim のセットアップをしようと思ったキッカケの一つに新しく MBP を買ったというのがあって、折角だから何か新しいことをやってみようかなと思った。つまり、本稿は完全な素人が個人的なメモとして書いてあるものだ。そもそもブログというのはそういうものなはずだ。動くかどうかは保証できない。全般的に yuroyoko さんが数年前に書いた iTerm2 + zsh + tmux + vim で快適な256色ターミナル環境を構築するを参考にした。

Vim 以外の色々なこと

dotfiles

本稿で書いたセットアップは eed3si9n/dotfiles に上げてある。他の人の dotfiles を fork するのが作法らしいけども、自分の環境に持ち込む設定をちゃんと理解したかったので、一から書き始めた。

dotfiles の基本的な考え方としては、これを ~/dotfiles/ にまず checkout して、そこには zshrc などのファイルが入ってる。これらのルートの設定ファイルはホームディレクトリ内で ~/.zshrc などという感じでシンボリックリンクが張られる。

Terminal.app

Mac で iTerm2 がどうしても必要になったことはまだない。以前には Terminal.app に色々と制限があったのかもしれないけど、今の所僕はこれで間に合っている。 Terminal.app を使い続けている理由のもう一つが、僕が TotalTerminal のファンであることだ。

homebrew

Homebrew にはお世話になっている。

Zsh

このマシンのシェルは Zsh にする。Mac なら How to use Homebrew Zsh Instead of Max OS X Default を参照:

$ brew install zsh
$ chsh -s /usr/local/bin/zsh

設定に関しては、zshrc は他の zshrc.* の読み込みだけを行っている:

Scala を用いたスクリプティング

現実問題として正規表現が必要になることがある。いくつかのテキストファイルに変換をかけたりする度に find コマンド、zsh のドキュメントや Perl 関連の StackOverflow の質問を手探りしながら作業することになる。苦労しながら Perl を書くよりは Scala を使いたい。結局、僕個人の慣れの問題だ。

例えば、今手元に 100以上の reStructuredText ファイルがあって、それを markdown に変換する必要がある。まずは pandoc を試してみて、それはそれなりにうまくいった。だけど、中身をよく読んでみるとコードリテラルの多くがちゃんとフォーマットされてないことに気づいた。これは単一のバッククォート (backtick) で囲まれていたり、Interpreted Text を使っているからみたいだ。このテキストをいくつかの正規表現で前処理してやればうまくと思う。

コマンドライン scalas

僕の現在の開発マシンには scala へのパスが通っていない。zip ファイルを一回ダウンロードするのは大した作業じゃないけども、将来的に jar とスクリプトの管理をしなきゃいけないのが面倒な気がする。普通なら僕は sbt を使って Scala の jar をダウンロードさせる。それでもいいけども、単一のファイルのみを使った解法が欲しいとする。

そこで今試してるのが sbt の script runnerだ:

#!/usr/bin/env sbt -Dsbt.version=1.4.7 -Dsbt.main.class=sbt.ScriptMain -Dsbt.supershell=false -error

/***
ThisBuild / scalaVersion := "2.13.4"
*/

println("hello")

次に、

$ chmod +x script.scala
$ ./script.scala
hello

これで自分の Scala version を 2.13.4 に指定するスクリプトができた。コンパイルを含めて “hello” が表示されるまで 8秒かかるから、サクサクとは程遠い感じだけど、個人的には許容範囲内だと思う。

sbt テクノロジ・プリビュー: auto plugin

Preview of upcoming sbt 1.0 features: Read about the new plugins を訳しました。

著 @eed3s9n, @jsuereth

sbt に変化が訪れようとしている。sbt 1.0 へ向けて sbt の原理である自動化 (automation)、インタラクション (interaction)、統合化 (integration) の全面において改善がみられる予定だ。1.0 の二大機能と目されているのは auto plugin と「ビルドサーバとしての sbt」の 2つだ。

今後の数ヶ月にわたって sbt チームは sbt 0.13 コードベース上にこれらの機能を追加したプリビュー版をリリースする。これらのプリビュー版によって、sbt 1.0 の仕様が固まる前にコミュニティーからのフィードバックを得たり、新しい設計方針や理念そして新機能を促進することを目的としている。

長い間 sbt を支えてきた Mark Harrah がビルド以外のことをするために旅立っていったことを残念ながら報告しなければならない。しかし、Typesafe のビルドツールチームである Antonio Cunei、Josh Suereth に新たなメンバー Eugene Yokota (@eed3si9n) が sbt の techlonogy lead の一人として参加することを歓迎したい。

本稿では、今回できあがった auto plugin 機能を紹介する。これは sbt 0.13.5-M2 リリースに含まれる。

プラグイン・エコシステム

sbt の最大の強みとしてプラグイン・エコシステムを挙げることができる。プラグインはビルド定義と全く同じように動くため、sbt を習うことはそのままプラグインを書くのを習うことにつながっていく。sbt プラグインの多様性はこの基本的なコンセプトの力強さを物語っているだろう。中でも Play Framework と Activator の二つは抜き出ている。これらは sbt の上にで作られていてインタラクティブな開発エクスペリエンスを提供しているからだ。

Scala でのクラス線形化 (mixin 順序) の制約

昨日は、何故か早朝に目が覚めて @xuwei_k氏のScalaで抽象メソッドをoverrideする際にoverride修飾子を付けるべきかどうかの是非を流し読みしていた。この話題は面白すぎたので、飛び起きてすぐに英訳してしまった。Scalaz で遭遇したコードを例にして型クラスのデフォルトインスタンスを提供することの微妙なジレンマを解説している。

以下に問題を簡略化したコード例を示す:

trait Functor {
  def map: String
}
trait Traverse extends Functor {
  override def map: String = "meh"
}
sealed trait OneOrFunctor extends Functor {
  override def map: String = "better"
}
sealed trait OneOrTraverse extends OneOrFunctor with Traverse {
}
object OneOr {
  def OneOrFunctor: Functor = new OneOrFunctor {}
  def OneOrTraverse: Traverse = new OneOrTraverse {}
}

これをテストするには以下を実行する:

scala> OneOr.OneOrTraverse.map
res0: String = meh

OneOr.OneOrTraverse.map は "better" を期待しているけども、map の実装は意図せずに Traverse のデフォルトインスタンスによって乗っ取られてしまった。

@xuwei_k氏は抽象メソッドのオーバーライド時に override 修飾子を付けるか否かの先行研究があるか聞いているので、考えてみよう。Scala は型クラスのインスタンス定義を項の空間と統合 (見方によってはコンプレクト) して、順序は継承関係によって指定されるので、関数型プログラミングというよりはモジュラープログラミングの話になる。Mixin 順序全般に関するトピックはクラス線形化 (class linearization) と呼ばれる。本稿で取り上げる内容はだいたいコップ本第二版にも書いてあることだと思う。

クラス線形化の補題

@xuwei_k氏の override のジレンマは以下の補題として言い換える事ができる:

• trait OneOrFunctor と Traverse があるとき、Traverse が OneOrFunctor の後にくるようなクラス線形化を禁止することができるか?

abstract override

普通の trait はインターフェイスのような役割をするのに対して、Scala は stackable traits を提供して、これはクラスの振る舞いを変更する。trait を stackable にするには、まずクラスか trait から継承して、メソッドに abstract override という修飾子を付ける。この修飾子の目的は、メソッド本文内から super へのアクセスを可能とすることだ。trait の super は動的に束縛されるため、通常はアクセスすることができない。

sbt-sequential を用いたタスクの逐次化

本稿では sbt 0.13 における実行意味論 (execution semantics) とタスクの逐次化 (task sequencing) についてみていこうと思う。まずは前提となる背景を大まかに復習して、次に逐次的タスク (sequential task) を追加するために書いた実験的プラグイン sbt-sequential を紹介したい。

背景

Mark 曰く:

sbt のモデルは副作用をタスクに局所化させることで、依存性さえ満たせば、タスクはいつでも実行できるというものだ。この利点はデフォルトで並列であることで、実際により速いビルドを可能とすることだ。

言い替えると、sbt を使ったビルド定義はタスク間の依存性のみを定義していて、これらのタスクがどのタイミングで始動されるかは sbt によって自動的に計算される。これをちゃんと理解するために、まず副作用を持った Scala コードの実行意味論をみてみよう。

直列実行 (serial execution)

class Test {
  def startServer(): Unit = {
    println("starting...")
    Thread.sleep(500)
  }
  def stopServer(): Unit = {
    println("stopping...")
    Thread.sleep(500)
  }
  def numberTask: Int = 1
  
  def integrationTest0(): Int = {
    val n = numberTask
    startServer()
    println("testing...")
    Thread.sleep(1000)
    stopServer()
    n
  }
}

誰かが integrationTest0() を呼び出すと、コードは書かれたのと全く同じ順序で実行される。まず numberTask が呼び出され、次に startServer() が呼ばれこの実行は 0.5 秒間かかる。メソッドが実行している間は戻ってくるまで制御はブロックされる。次に println("testing...") が呼ばれるといった具合だ。このような順序の入れ替えを伴わず、またオーバーラップを伴わない実行は直列実行 (serial execution) と呼ばれる。

Spire の Ops マクロ: 暗黙の演算子の高速化

一見普通の演算でもいかに高速化できるかをいつも考えて発表してる奇才 Eiríkr Åsheim (@d6) さんの “How to use Spire’s Ops macros in your own project” を翻訳しました。いつも気さくに話しかけてくれるフレンドリーでいいやつです。翻訳の公開は本人より許諾済みです。

2013年10月13日 Eiríkr Åsheim 著 2013年11月20日 e.e d3si9n 訳

Spire の Ops マクロとは何か?

Spire の型クラスは + や * といった基礎的な演算子を抽象化する。普通これらの演算は非常に速い。そのため、ちょっとでも余計な事 (例えば、boxing やオブジェクトの割り当てなど) を演算ごとにやってしまうと、ジェネリック化したコードは直接呼び出したものと比べて遅いものになってしまう。

効率的かつジェネリックな数値プログラミングが Spire の存在意義だ。不必要なオブジェクト割り当てを回避するために僕たちはいくつかの Ops マクロを用意した。本稿ではその仕組みと、君のコードからそれらのマクロを使う方法を解説する。

通常の型クラスを用いた暗黙の演算子の仕組み

Scala で型クラスを用いる場合、通常は暗黙の変換に頼ることでジェネリックな型に演算子を「追加」する。(訳注: いわゆる Enrich my library パターンだ)

以下に具体例で説明すると、A はジェネリックな型、Ordering は型クラスで、> が暗黙の演算子となる。foo1 はプログラマが書くコードで、foo4 は implicit が解決されて、糖衣構文が展開された後のものだ。

import scala.math.Ordering
import Ordering.Implicits._

def foo1[A: Ordering](x: A, y: A): A =
  x > y

def foo2[A](x: A, y: A)(implicit ev: Ordering[A]): A =
  x > y

def foo3[A](x: A, y: A)(implicit ev: Ordering[A]): A =
  infixOrderingOps[A](x)(ev) > y

def foo4[A](x: A, y: A)(implicit ev: Ordering[A]): A =
  new ev.Ops(x) > y

(実はこれは微妙に間違っている。foo4 への展開は実行時に infixOrderingOps が呼ばれるまでは行われないが、これから説明することの要点となる。)

sbt 0.13 を用いた四次元空間内の移動

警告: この sbt についての覚え書きは中級ユーザ向けだ。

セッティングシステム

sbt 0.12 同様に sbt 0.13 の中心にあるのはセッティングシステムだ。Settings.scala を見てみよう:

trait Init[Scope] {
  ...

  final case class ScopedKey[T](
    scope: Scope,
    key: AttributeKey[T]) extends KeyedInitialize[T] {
    ...
  }

  sealed trait Initialize[T] {
    def dependencies: Seq[ScopedKey[_]]
    def evaluate(map: Settings[Scope]): T
    ...
  }

  sealed class Setting[T] private[Init](
    val key: ScopedKey[T], 
    val init: Initialize[T], 
    val pos: SourcePosition) extends SettingsDefinition {
    ...
  }
}

pos を無視すると、型 T のセッティングは、型が ScopedKey[T] である左辺項 key と型が Initialize[T] である右辺項 init によって構成される。

第一次元

便宜的に ScopedKey[T] は、現在のプロジェクトなどのデフォルトのコンテキストにスコープ付けされた SettingKey[T] や TaskKey[T] だと考えることができる。すると残るのは Initialize[T] だけで、これは依存キーの列と何らか方法で T へと評価される能力を持っている。Initialized[T] に直接作用するのはキーに実装されている <<= 演算子だ。Structure.scala 参照:

sealed trait DefinableSetting[T] {
  final def <<= (app: Initialize[T]): Setting[T] = 
    macro std.TaskMacro.settingAssignPosition[T]
  ...
}

名前から推測して、このマクロは pos を代入しているのだと思う。sbt 0.12 においてはキーのタプルにモンキーパッチされた apply や map メソッドによって Initialize[T] が構築された。sbt 0.13 ではスマートな := 演算子を使うことができる。Structure.scala 参照:

オブジェクト指向プログラミングとは何か?

oop はどう定義されるべきだろうか?

純粋オブジェクト指向プログラミング

純粋オブジェクト指向プログラミングは以下のように定義できる:

オブジェクトを使ったプログラミング。

オブジェクトとは何か?

他のオブジェクトへの参照を保持し、事前にリストアップされたメッセージを受信することができ、他のオブジェクトや自分自身にメッセージを送信することができるアトムで、他には何もしない。メッセージは名前とオブジェクトへの参照のリストから構成される。

これでおしまい。言い回しは僕が考えたものだけど、アイディアはオブジェクト指向という言葉を作った張本人 Alan Kay (2003) からのものだ。これ以外は、直接 oop に関係無いか、実装上の詳細だ。

sbt 0.13.0 の変更点

概要

互換性に影響のある新機能、変更点、バグ修正

• sbt とビルド定義を Scala 2.10 に移行した。
• project/plugins/ 内に置かれたプラグインの設定ファイルのサポートを廃止した。これは 0.11.2 より廃止予定になっていた。
• set コマンドにおいてセッティングの右辺項内のタブ補完を廃止した。新たに追加されたタスクマクロがこのタブ補完を不要にするからだ。
• キーの慣用的な書き方はこれよりキャメルケース camelCase のみとする。詳細は後ほど。
• Maven との互換性を正すため、テストのデフォルトの classifier を tests に修正した。
• グローバルなセッティングとプラグインのディレクトリをバージョン付けるようにした。デフォルトでは、グローバルセッティングは ~/.sbt/0.13/ に、グローバルプラグインは ~/.sbt/0.13/plugins/ に置かれる。sbt.global.base システムプロパティを使った明示的なオーバーライドは継続して適用される。(#735)
• scalac にファイルを渡すときに sbt が行なっていた正規化 (canonicalization) を廃止した。(#723)
• 各プロジェクトがそれぞれ固有の target ディレクトリを持つことを強制するようにした。
• 依存ライブラリの Scala バージョンをオーバーライドしないようにした。これによって個別の設定が異なる Scala バージョンに依存できるようになり、scala-library 以外の Scala 依存性を通常のライブラリ依存性と同じように扱えるようになった。しかし、これによってその他の scala-library 以外の Scala ライブラリが最終的に scalaVersion 以外のバージョンに解決される可能性も生まれた。
• Cygwin での JLine の設定が変更された。Setup 参照。
• Windows 上での JLine と Ansi コードの振る舞いが改善された。CI サーバ内では -Dsbt.log.format=false を指定して明示的に Ansi コードを無効にする必要があるかもしれない。
• フォークされたテストや run がプロジェクトのベースディレクトリをカレント・ワーキング・ディレクトリとして用いるようにした。
• compileInputs は Compile ではなく (Compile,compile) 内で定義するようにした。
• テストの実行結果は Tests.Output になった。

新機能

• boot.properties 内のレポジトリをデフォルトのプロジェクトの resolver として用いる。boot.properties 内のレポジトリに bootOnly と書くことでデフォルトでプロジェクトに使用されないようにすることができる。 (Josh S., #608)
• .sbt ファイル内で val や def を書けるようにした。詳細は後ほど。
• .sbt ファイル内でプロジェクトを定義できるようにした。Project 型の val をビルドに追加することになる。詳細は後ほど。
• セッティング、タスク、およびインプット・タスクの新構文。詳細は後ほど。
• autoAPIMappings := true とすることで、依存ライブラリの外部 API scaladoc に自動的にリンクするようにした。これは Scala 2.10.1 を必要とし、apiURL を使って依存ライブラリの scaladoc の場所を指定する必要がある。apiMappings タスクを使って手動でマッピングを提供することもできる。
• スイッチコマンドを使って一時的に Scala ホームディレクトリを設定できるようにした: ++ scala-version=/path/to/scala/home。 だたし、scala-version の部分は省略可能だが、マネージ依存性の解決に用いられる。
• ~/.m2/repository に公開するための publishM2 コマンドを追加した。(#485)
• ルートプロジェクトが定義されていない場合は、全てのプロジェクトを集約するデフォルトのルートプロジェクトを用いる。(#697)
• 複数のプロジェクトやコンフィギュレーションからタスクやセッティングを取得するための新しい API を追加した。Getting values from multiple scopes参照。
• テストフレームワークの機能をより良くサポートするためにテストインターフェイスを改善した。（詳細は）
• export コマンド
  • タスクの場合は、export ストリームの内容を表示する。慣例としては、タスクと等価のコマンドラインを表示する。例えば、compile、doc、console はそれらを実行する近似的なコマンドラインを表示する。
  • セッティングの場合は、ロガーを経由せずにセッティングの値を直接表示する。

バグ修正

• 依存ライブラリの衝突を警告しないようにした。代わりに conflict manager を設定する。(#709)
• フォークされたテストを実行するときに Cleanup と Setup を実行するようにした。別の JVM で実行されるため、クラスローダは使うことができない。

改善点

• API 抽出フェーズを、typer フェーズではなく picker フェーズの後で実行することで typer の後にコンパイラプラグインを置けるようにした。(Adriaan M., #609)
• セッティングのソース内における位置を記録するようにした。inspect は定義された値に関わる全てのセッティングの位置を表示する。
• Build.rootProject 内にルートプロジェクトを明示的に指定できるようにした。
• キャッシュ情報を保存するためのディレクトリが必要なタスクは stream の cacheDirectory を使えるようになった。これは cacheDirectory セッティングに取って代わる。
• フォークされた run や test によって使われる環境変数が envVars によって設定できるようになった。これは Task[Map[String,String]] だ。(#665)
• コンパイルに失敗した場合にクラスファイルを復旧するようにした。これはエラーがインクリメンタルコンピレーションの後ろの方の過程で発生しているが修正するには元の変更されたファイルを直す必要がある場合に役に立つ。
• デフォルトプロジェクトの自動生成ID を改善した。(#554)
• scala コマンドによる余計なクラスローダを回避するためにフォークされた run は java コマンドを使うようにした。(#702)
• autoCompilerPlugins が内部依存プロジェクト内で定義されたコンパイラプラグインを使えるようにした。ただし、プラグインのプロジェクトは exportJars := true を定義する必要がある。プラグインに依存するには ...dependsOn(... % Configurations.CompilerPlugin) と書く。
• 非プライベートなテンプレートの親クラスを追跡することで、インクリメンタルコンピレーション時により少なく小さい中間ステップを必要とするようにした。
• インクリメンタルコンパイラによって抽出された API の内部構造をデバッグするためのユーティリティを追加した。(Grzegorz K., #677, #793)
• consoleProject はセッティングの値の取得とタスクの実行を統合した構文を提供する。Console Project 参照。

その他

• Eclipse ユーザの便宜のために sbt プロジェクト自体のソースのレイアウトをパッケージ名に沿ったものに変更した。(Grzegorz K., #613)

大きな変更点の詳細

キャメルケースのキー名

これまでのキー名の書き方は、Scala の識別子はキャメルケースで、コマンドラインではハイフンでつなげた小文字という慣用だったが、これからは両方ともキャメルケースに統一する。既存のハイフン付けされたキー名に対してもキャメルケースを使うことができ、また既にあるタスクやセッティングに対しては継続してハイフン付けされた形式も受け付ける。しかし、タブ補完はキャメルケースのみを表示するようになる。

シンプルさの必要性

2012年4月23日にテキサスの Austin で行われた RailsConf 2012 での Rich Hickey (@richhickey) さんによる基調講演、Simplicity Matters を書き起こして翻訳しました。 Rich Hickey さんは Clojure や Datomic の作者です。 この翻訳は Creative Commons Attribution ShareAlike 3.0 ライセンスに基いて公開します。

Rich Hickey 講演 e.e d3si9n 訳

Scala: 空飛ぶサンドイッチのパーツ

JavaScript が作られたのは 1995年のことだから、『JavaScript: The Good Parts』(2008年)、jQuery (2006年)、V8 (2008年) などが登場するよりもかなり前に作られたことになる。jQuery と V8 が加算的な貢献であるのに対して、Douglas Crockford 氏の『The Good Parts』が面白いのは、言語から機能を引き算した本であることだと思う。

ここ最近、もし Scala をリアルワールドな制約である Java 的な親しみやすさや互換性を無視してワンダーランド的な設定でサブセットを作ったらどうなるだろうかと考えている。Scala を Java の代替として使う事が許されるなら、関数型プログラミング言語の代替として使ってもいいじゃないかと思う。この思考実験のもう一つの試みは、Scala の構文の中で重複しているものを減らすことだ。本稿では、慣用的な用法が何かを考えたり、何かに対して良し悪しの判定を下すことには興味は無い。これは空飛ぶサンドイッチのパーツ (The Flying Sandwich Parts; TFSP) と呼ぶことにする。

値

What talk you of the posy or the value? — William Shakespeare, Merchant of Venice

Scala 言語仕様は値を以下のように定義する:

値定義 val x : T = e は、e の評価から得られる値の名前として x を定義します。

TFSP においては、トレイトやクラスの本文内では型注釈 T の省略を禁止する。関数内のローカルの値は型推論を使って定義してもよい。これによって関数レベルにおいて型検査が行われることが保証される。

遅延評価値

素の val を使って値を定義すると、定義した順番に気を使う必要がある。初期化する前に値を参照してしまうと実行時に NullPointerException が発生してしまう。値を lazy だと書くことで最初に参照されるまで初期化を遅延することができる。