scopt 3.0

scopt is a little command line options parsing library.

今日 scopt 3.0 をリリースする。実装の詳細に興味が無ければ、readme に飛んでほしい。

2010年3月4日ごろ僕は scopt のコミッタになった。これは元々 Aaron Harnly さんが 2008年ごろ書いた scala-options のフォークだ。確か、usage text 周りの変更と key=value options と argument list という機能を追加したかったんだと思う。それ以降全てのバグレポを担当してきた。その中には jar を scala-tools.org に公開してくれというのもあった。2012年3月18日、僕は再びプロジェクトを scopt/scopt にフォークして immutable parser を追加した scopt 2.0.0 をリリースした。

数年に渡って重ねるようにして機能が追加されたため、scopt3 は一から書き直すことにした。発端となったのは Leif Wickland さんに「scopt に intArg() が無いのは設計上の理由があるのか」と聞かれたことだ。

Ruby の OptionParser に inspire されて書かれた元の Aaron さんの scala-options にはオプションのために 5個のメソッドがあった: onInt、 onDouble、 onBoolean、 on、それからもう一つオーバーロードされた on。重なる開発の結果 scopt2 は opt のオーバーロードが 6つ、intOpt、 doubleOpt、 booleanOpt、 keyValueOpt、 keyIntValueOpt、 keyDoubleValueOpt、 keyBooleanValueOpt それぞれに 4つづつのオーバーロードが蓄積された。合計 34 ものメソッドだ! これらのオーバーロードは省略可能な頭文字や値の名前のために僕が追加したものだから、自分以外に責めようが無い。これ以上の拡張は考えられなかった。

Dispatch プラグインの書き方

Dispatch は Scala からネットへつなぐデファクトの方法であり続けてきた。昨今のノンブロッキングIO への流れと歩調を合わせて @n8han はライブラリを Async Http Clientベースのものに書きなおし、Reboot と呼んだ。後にこれは、Dispatch 0.9 としてリリースされる。さらに、独自の Promise を SIP-14 で標準化された Future に置き換えたものが Dispatch 0.10 だ。

Dispatch Classic 同様に Reboot でも web API をラッピングしたプラグインを作ることができる。本稿では、Classic で書かれたプラグインを移植しながら Dispatch 0.10 プラグインの書き方を解説していく。

repatch-twitter

他のプラグインとの名前の衝突を回避するために、僕のは dispatch-twitter ではなく repatch-twitter と呼ぶことにする。

sbt

まずは sbt の設定から始める:

repatch-twitter/
  +- project/
  |    +- build.properties
  |    +- build.scala
  +- core/
       +- src/
            +- main/
                 +- scala/
                      +- requests.scala
                      +- ...

build.properties の中身:

カンファレンスを翻訳する

もう一ヶ月経つけど 2013年3月1日に日本に一時帰国して「Scala Conference in Japan 2013」に出席した。そういう名前のカンファレンス。

ポッドキャストから

ある日 (2012年6月2日だけど) Scala Days 2012 で録音された Scala Types を聞いていると誰かが (@timperrett さん) “I would love to see Scala Days in Asia. We had two in Europe now. It would be wicked to have it in China or Japan, or somewhere like that.” と言っていたので、その趣旨を Twitter で伝えた:

今 Scala Days 2012 で録音された Scala Types を聴いてたら、開催地が欧米圏に偏ってるから次あたり日本とかアジア圏なんてどうだろうって話が出てた。コミュニティが声出せば誘致もありえるかも

会話が始まると @jsuereth がすぐに支持の声を上げてくれた:

@kmizu @eed3si9n_ja If you guys manage to get a Scala conference somewhere in asia, I’ll be there!

Read More…

抽象的な Future

これは Scalaz Advent Calendar 2012 12日目の記事です。

次々と Scala 界の知能派を集結させている Precog 社の開発チームからのブログ Precog.Copointed。今日は blueeyes などの開発でも知られる Kris Nuttycombe (@nuttycom) さんが書いた The Abstract Future を翻訳しました。翻訳の公開は本人より許諾済みです。

2012年11月27日 Kris Nuttycombe 著 2012年12月11日 e.e d3si9n 訳

Precog 開発ブログの前回は僕たちが Cake パターンを使ってコードベースを構造化して、ギリギリまで実装型を抽象化してしていることを Daniel が書いた。その記事での説明のとおり、これは非常に強力な概念だ。型を存在型として保つことで、やがて選択された型を「意識」していないモジュールからはそれらの型の値は不可視であるため、カプセル化の境界の突破をコンパイラが防止してくれる。

今日の記事では、この概念を型からさらに進めて型コンストラクタに適用して、計算モデルを丸ごと置き換える機構として使えることを説明する。

Scala を少しでも使ったことがあれば、何らかの文脈で誰かが「モナド」という言葉を使ったのを聞いたことがあるだろう。例えば、Scala の for というキーワードにより提供される糖衣構文に関する議論か、Option 型を使うことで null 参照エラーの落とし穴が回避できることを説明したブログ記事で読んだのかもしれない。Scala でのモナドに関する議論の大半が「コンテナ」型に焦点を当てているのに対して、Scala エコシステムでよく見かけるいくつかの型の中にモナディック合成のより面白い側面が表れるものがある。限定計算 (delimited computation) だ。どのモナディックな型を合成してもこの側面を見ることができるが、これを直接利用した例として最もよく使われている Scala でのモナディックな型に非同期計算をエンコードした akka.dispatch.Future がある (これは Scala 2.10 において現行の Future を置き換える予定のものだ)。これは計算のステップを順序付けするための柔軟な方法を提供することで、本稿が注目するモナディック合成の一面を体現する。

ここで一言断っておくが、この記事はモナドのチュートリアルとして機能することを意図していない。モナドの解説とその Scala のプログラミングとの関連を取り扱った記事は既にたくさんある (ありすぎるかも!)。もしこの概念に不慣れなら読み進める前にそれらの解説を読むと役に立つかもしれない。しかし、最初に注意しておきたい点が一つあって、(モナディック合成のための糖衣構文としての for が示すとおり) Scala ではモナドは広い範囲で利用されているにも関わらず Scala の標準ライブラリに Monad 型が無いというのは Scala 固有な状況だということだ。そのため、モナド型が必要ならば標準ライブラリ外の素晴らしい Scalaz プロジェクトを使う。Scalaz のモナド抽象体は implicit 型クラスパターンを利用している。以下にベースの Monad 型を簡略化したものを示す:

Func を使った数独

これは Scalaz Advent Calendar 2012 5日目の記事です。

12月の間中、日本の技術系ギークは日替わりでテーマに沿った記事を公開し、彼の国では「Advent Calendar」と呼ばれているらしい。去年の Scala Advent Calendar 2011 で僕は Eric Torreborre さんが The Essence of Iterator Pattern をカバーした記事を翻訳した。これは日本人の関数型プログラミング記事好きを知った上である程度狙ったものだった。もう1つの利己的な動機は、記事を一語一語訳す過程において概念のいくつかは僕の頭にも染みこんでくれるんじゃないかという期待だった。振り返ってみると、両方の目的とも作戦成功だったと言える。Jeremy Gibbons さん、Bruno Oliveira さんそして Eric 両方の仕事のクオリティのお陰だ。これらの染み込んだ知識が今年に書いた独習 Scalaz シリーズの隠し味だったんじゃないかと思っている。

独習 Scalaz 12日目でふれたとおり、Scalaz 7 の型クラスインスタンスには既に product と compose が含まれており、また Traverse も定義されている。論文にある word count の例題 まである。僕が気づいたのは、値レベルでの合成が無いことだ。この論文の興味深い点の1つに「applicative functor の合成」があり、これはモジュール化プログラミング的なものを可能とする。

Gibbons と Oliveira の言う「applicative functor」は実は型クラスのインスタンスだけではなく、applicative 関数の合成も指している。これは論文からの以下の抜粋をみれば明らかだ:

data (m ⊠ n) a = Prod { pfst :: m a, psnd :: n a }
(⊗) :: (Functor m, Functor n) ⇒ (a → m b) → (a → n b) → (a → (m ⊠ n) b)
(f ⊗ g) x = Prod(f x)(gx)

代数データ型の ⊠ は型レベルの積だが、中置関数の ⊗ は 2つの applicative 関数の値レベルの積で、a → (m ⊠ n) という型の applicative 関数を返す。言い換えると、プログラマは applicative functor を返す関数を構築するだけよくて、型レベルでの合成は自動的に行われる。

絵で見るモナド

John Wiegley さんの “Monads in Pictures” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。

2012年8月20日 John Wiegley 著 2012年8月21日 e.e d3si9n 訳

これはモナドのチュートリアルではないし、ここには数学用語も出てこない。本稿は、既にモナドを一応使えるぐらいには習った人を対象とする。視覚化することで、何のために何をやっているかが明らかになるはずだ。

関数

モナドに対する直感を得る一つの方法として関数からモナドへの抽象化をたどるというものがある。関数が何をやっているのかを簡単な絵で表してみよう。Haskell の関数の呼び出しの構文を上に、同じ演算を視覚化したものを下に置いた:

Scala 2.10 におけるメタプログラミング: 構文木、シンボル、型について

Scala マクロの作者 Eugene Burmako さんによるリフレクション API に関する発表のスライド、“Metaprogramming in Scala 2.10” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。

2012年4月28日 Eugene Burmako 著 2012年8月5日 e.e d3si9n 訳

はじめに

メタプログラミング

メタプログラミングとは、他のプログラムや自身をデータとして書いたり操作するコンピュータプログラムを書くこと。　—Wikipedia

コンパイラ

問: どうやってメタプログラミングを可能にすることができだろう?

答: コンパイラよりもプログラムに関してデータを持つ者がいるだろうか?

プログラマにコンパイラを公開しよう。

リフレクション

2.10 ではプログラムに関するデータをリフレクション API として公開する。

この API は、scala-library.jar (インターフェイス)、scala-reflect.jar (実装)、scala-compiler.jar (実行時コンパイル) にまたがっている。

Martin の方が詳しい

先日行われた Martin Odersky 先生による講演にてリフレクション API の設計が詳しく説明されている:

• http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Reflection-and-Compilers

実習

今日は、いくつかの具体例を通してリフレクション API の基礎を習い、またどうやって更に多くの情報を得られるかを習う。

マクロ

問: ちょっと! マクロはどうなってるの?

答: マクロの核となるのはリフレクションであり、リフレクションがマクロを API として提供し、リフレクションがマクロを可能とする。今日はまずリフレクションを理解することに焦点を当てる。マクロは小さな後付けにすぎない。

マクロ、その哲学と応用に関しては、Scala Days での講演を参考にしてほしい:

• http://eed3si9n.com/ja/scala-macros-scaladays2012

リフレクション

コアとなるデータ構造

• 構文木 (Tree)
• シンボル (Symbol)
• 型 (Type)

$ scalac -Xshow-phases
phase name id description
---------- -- -----------
    parser  1 ソースを AST へとパースし、簡単な糖衣構文展開 (desugaring) を行う。
     namer  2 名前を解決し、シンボルを名前付けされた構文木へと関連付ける。
     typer  4 メインコース: 構文木を型付けする。
   pickler  7 シンボルテーブルをシリアライズする。

できる限り分かりやすくこれらの概念の説明をするつもりだが、Paul Phillips 以上の説明は恐らく誰にもできない。 Inside the Sausage Factory という講演は絶対に見ておいたほうがいい。

初めての Scala マクロ

Scala マクロの作者 Eugene Burmako さんが管理する scalamacros.org から “Getting started” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。

Eugene Burmako 著 2012年7月31日 e.e d3si9n 訳

1. Scala 2.10 を入手する

マクロは 2.10.0-M3 以降の Scala で出荷されている。現行のマイルストーンである 2.10.0-M6 などのマクロが入ったコンパイラを直接ダウンロードするか、Maven や sbt などから参照する。好きな方法を使っていい。

訳注: sbt 0.11.3 を使ったプロジェクトを github に用意したので、

git clone -b ja https://github.com/eed3si9n/scalamacros-getting-started.git

でセットアップできる。

2. マクロを書く

Macros.scala というファイルを作って以下のコードをペーストする (関連する API やインフラなどマクロシステムに大切なことが書かれているのでコメントもしっかり読んでほしい)。

import scala.reflect.makro.Context
import collection.mutable.ListBuffer
import collection.mutable.Stack

object Macros {
  // マクロ定義のシグネチャは好きなパラメータを受け取る普通の関数と同じだ。
  // しかし、本文は実装への参照のみとなる。
  def printf(format: String, params: Any*): Unit = macro printf_impl

  // マクロ実装のシグネチャはマクロ定義のものと対応する必要がある。
  // 一見複雑に見えるが、心配する必要はない。
  // もしコンパイラが不満なら、エラーメッセージで必要なシグネチャを教えてくれる。
  def printf_impl(c: Context)(format: c.Expr[String],
    params: c.Expr[Any]*): c.Expr[Unit] = {
    
    // コンパイラ API は scala.reflect.makro.Context を通じて公開されている。
    // その最も重要な部分であるリフレクション API は
    // c.universe よりアクセスすることができる。
    // 頻繁に使われるものの多くが含まれているため、
    // import c.universe._ をインポートするのが慣例だ。
    import c.universe._

    // まず、渡された format 文字列をパースする。
    // マクロはコンパイル時に動作するため、値ではなく構文木に作用する。
    // そのため、このマクロに渡される format パラメータは
    // コンパイル時のリテラルであり、
    // java.lang.String 型のオブジェクトではない。
    // これはまた、以下のコードでは printf("%d" + "%d", ...) では
    // 動作しないことを意味する。
    // なぜならこの場合は format は文字リテラルではなく 
    // 2つの文字リテラルの連結を表す AST となるからだ。
    // 任意のもので動作するようにこのマクロを改良するのは読者への練習問題としよう。
    val Literal(Constant(s_format: String)) = format.tree

    // ここからコンパイラに突入する。
    // すぐ下のコードでは一時的な val を作ってフォーマットされる式を事前に計算する。
    // 動的な Scala コードの生成に関してより詳しく知りたい場合は以下のスライドを参照:
    // http://eed3si9n.com/ja/metaprogramming-in-scala-210
    val evals = ListBuffer[ValDef]()
    def precompute(value: Tree, tpe: Type): Ident = {
      val freshName = newTermName(c.fresh("eval$"))
      evals += ValDef(Modifiers(), freshName, TypeTree(tpe), value)
      Ident(freshName)
    }

    // ここはありがちな AST に対する操作で、特に難しいことは行なっていない。
    // マクロのパラメータから構文木を抽出し、分解/解析して変換する。
    // Int と String に対応する Scala 型を手に入れている方法に注意してほしい。
    // これはコアとなるごく一部の型ではうまくいくが、
    // ほとんどの場合は自分で型を作る必要がある。
    // 型に関しての詳細も上記のスライド参照。
    val paramsStack = Stack[Tree]((params map (_.tree)): _*)
    val refs = s_format.split("(?<=%[\\w%])|(?=%[\\w%])") map {
      case "%d" => precompute(paramsStack.pop, typeOf[Int])
      case "%s" => precompute(paramsStack.pop, typeOf[String])
      case "%%" => Literal(Constant("%"))
      case part => Literal(Constant(part))
    }

    // そして最後に生成したコードの全てを Block へと組み合わせる。
    // 注目してほしいのは reify の呼び出しだ。
    // AST を手っ取り早く作成する方法を提供している。
    // reify の詳細はドキュメンテーションを参照してほしい。
    val stats = evals ++ refs.map(ref => reify(print(c.Expr[Any](ref).splice)).tree)
    c.Expr[Unit](Block(stats.toList, Literal(Constant(()))))
  }
}

3. マクロをコンパイルする

準備はできた? scalac Macros.scala と打ち込んでみよう。

Scala マクロ、ロンドンに現る

マクロの作者として今注目を浴びている Eugene Burmako さんと、マクロを使って言語統合されたデータベース接続行うライブラリ SLICK の作者である Jan Christopher Vogt さんが今年の Scala Days で行った発表のスライドを翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。

2012年4月18日 Eugene Burmako、Jan Christopher Vogt 著 2012年7月30日 e.e d3si9n 訳

Scala マクロ

(頭をおかしくせずに) コンパイラを拡張する権限を開発者に与える!

これはコンパイル時に以下を行う:

• 検査
• 処理
• AST 変換
• コード生成
• ランタイムへの AST の配備

訳注: Scala マクロは 2.10 より導入されるコンパイル時にコードを置換する機構だ。これにより今までボイラープレートが必要だったものを自動生成できるようになるなど、より高い表現力を手にすることができる。

Scala脳のための C# LINQ

これは Scala プログラマのための C# LINQ 機能の覚え書きだが、逆としても使えるはず。

型推論

C# には型推論がある。個人的に、ローカル変数ではできるだけ var を使うようにしている。

Scala にも var があるけど、可能なら不変 (immutable) な val を使うのが好ましいとされている。

val x = 1

新しい List と Array の作成

C# はインラインでコレクションを作ることができる。

val list = List("Adam", "Alice", "Bob", "Charlie")
val array = Array(0, 1, 2)

sbt 0.12.0 の変更点

ついに final がリリースされた、sbt 0.12.0 の変更点を訳しました。 バイナリバージョンという概念が導入されることで、Scala 2.9.0 で入ったけどあまり活用されていない Scala の後方バイナリ互換性がより正面に出てくるキッカケとなると思います。

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

• Scala 2.10 以降の Scala 及び sbt プラグインのクロスバージョン規約の変更。 (詳細は以下の項目 )
• 直接実行された場合、強制的に update を実行するようにした。 #335
• sbt プラグインリポジトリがプラグインとプラグインの定義にデフォルトで加わった。 #380
• プラグイン設定ディレクトリの優先順位。 (詳細は以下の項目 )
• ソース依存性の修正。 (詳細は以下の項目 )
• 集約がより柔軟になった。 (詳細は以下の項目 )
• タスク軸の構文が key(for task) から task::key へと変更された。 (詳細は以下の項目 )
• sbt の organization が org.scala-sbt へと変更された。(元は、org.scala-tools.sbt) 特に、scripted プラグインのユーザはこの影響を受ける。
• artifactName の型が (ScalaVersion, ModuleID, Artifact) => String となった。
• javacOptions がタスクとなった。
• session save は build.sbt 内の設定を（適切な時に）上書きするようにした。#369

新機能

• テストのフォークのサポート。 #415
• test-quick。 (#393)
• リポジトリ設定のグローバルなオーバライドをサポートした。 #472
• 再コンパイルをせずに unchecked と deprecation の警告を表示する print-warnings タスクを追加した。(Scala 2.10+ のみ)
• Ivy 設定ファイルを URL から読み込めるようにした。
• projects add/remove で一時的に他のビルドと作業できるようになった。
• 並列実行の制御の改善。 (詳細は以下の項目 )
• inspect tree で inspect を再帰的に呼べるようになった。#274

バグ修正

• 再帰的にディレクトリを削除するときに、シンボリックリンクが指す先のコンテンツを削除しないようにした。
• Java ソースの親の検知の修正。
• update-sbt-classifiers で用いられる resolver の修正。#304
• プラグインの自動インポートの修正。#412
• 引数のクオート #396
• Ctrl+Z で停止した後 JLine を正しくリセットするようにした。(Unix のみ) #394

改善点

• ランチャーが 0.7.0 以降全ての sbt を起動できるようになった。
• スタックトレースが抑制された場合、last を呼ぶようにより洗練されたヒントが表示されるようになった。
• Java 7 の Redirect.INHERIT を用いて子プロセスの入力ストリームを継承するようになった。 #462, #327 これでインタラクティブなプログラムをフォークした場合に起こる問題が解決されるはず。 (@vigdorchik)
• help と task コマンドの様々な改善、および新たな settings コマンド。#315
• jsch バージョンを 0.1.46 へと更新。 #403
• JLine バージョンを 1.0 へと変更。 (詳細は以下の項目 )
• その他の修正および機能改善: #368, #377, #378, #386, #387, #388, #389

実験的、もしくは開発途中

• 差分コンパイルを組み込むための API。このインターフェイスは今後変更する可能性があるが、既に scala-maven-plugin のブランチで利用されている。
• Scala コンパイラの常駐の実験的サポート。 sbt に -Dsbt.resident.limit=n を渡すことで設定を行う。n は常駐させるコンパイラの最大数。
• 新サイトの howto ページを読みやすくした。

大きな変更の詳細点

sbt プラグインのまとめ

XML ベースのビルドツールと比較すると sbt はビルド定義を (.sbt と .scala の両方とも) Scala を使って書くという違いがある。それにより一度 sbt のコンセプトや演算子を押さえてしまえば、ビルドユーザが sbt プラグインを書き始めるのにあまり労力がいらない。

既にあった sbt 0.7 のプラグインも移植してきたが、オリジナルのも書いているのでまとめて紹介したい。

sbt-dirty-money

sbt-dirty-money は Ivy キャッシュを何となく選択的に消去するためのプラグインだ (~/.ivy2/cache 下の organization と name を含むもの)。たった 25行の簡単な実装だけど、clean-cache と clean-local の 2つのタスクは僕の役に立っている。

例えば、何かプラグインを開発していてそれがテスト用の hello プロジェクトにおいてキャッシュされているかどうかが不明であるとする。 プラグインプロジェクト中から clean-cache と clean-local の両方を走らせ、hello プロジェクトを reload することでプラグインが解決できないかどうかを確認する。解決できなければ、どこか知らない所から引っ張ってきてるわけではないということなので成功だ。

sbt-buildinfo

sbt-buildinfo は前から書こうと思っていたプラグインの一つだ。これはビルド定義から Scala のソースを生成する。主な目的はプログラムが自身のバージョン番号を意識することにある (特に、conscript を使ったアプリの場合)。

sourceGenerators を使ってバージョン番号を含むオブジェクトを生成するスクリプトをちゃちゃっと書いたことが何回かあったが、他の人にも使ってもらえるようにするにはプラグインにするのが適してると思った。state から値を抽出することで sbt-buildinfo は任意の複数のキーから Scala ソースを生成する。以下を build.sbt に加える:

buildInfoSettings

sourceGenerators in Compile <+= buildInfo

buildInfoKeys := Seq[Scoped](name, version, scalaVersion, sbtVersion)

buildInfoPackage := "hello"

これで以下が生成される:

Scala 並列コレクションライブラリ

並列コレクションライブラリのガイドを翻訳して、docs.scala-lang.org に取り込んでもらいました。 原文は EPFLの研究アシスタントで、並列コレクションの設計書である A Generic Parallel Collection Framework (pdf) という論文の第一著者でもある Aleksandar Prokopec さんと 現在アメリカから EPFL に留学中で、並列と分散プログラミングモデルを研究していて、コミュニティ内ではドキュメンテーションツァーとしても知られる Heather Miller さんです。

• Scala 並列コレクションライブラリ

treehugger.scala pamflet

treehugger はコードを用いて Scala のソースコードを書くためのライブラリだ。それはまた、Refelection API に基づく Scala AST の代替実装の一つでもあり、github で eed3si9n/treehugger として公開している。

更新: この記事を拡張して本当かっこいい n8han/pamflet を使ってガイドに仕上げてみました（今のところ英語だけです）:

• treehugger のパンフレット

暗黙のパラメータ解決優先順位

Scala という言語は、僕の使ったことのある中では最もエレガントで、表現力に富み、一貫性があり、かつ実利的な言語の一つだと思う。パターンマッチングや統一形式アクセスの原則などはじめ、その筋の良さは枚挙にいとまがない。そして、Scala エコシステムと Scala コミュニティーはその言語をより強力なものにしている。

Scala 2.9.1 において、ローカルで宣言された implicit はインポートされたものよりも優先される。問題は、言語仕様にはそのような振る舞いは書かれていないことだ。僕の当初の仮説は、自分が言語仕様を正しく理解していないか、もしくは言語仕様に抜け穴があるかのどちらかだろうというものだった。とにかく、その仮説に基づいて暗黙のパラメータ解決の優先順位について色々調べた結果を先週書いた。「怪しい伝説」でもよく言われるように、全く予期していなかった結果が出てきたときが最も面白いものとなる。後で分かったのは、仮説の両方とも間違っていたということだ。

つまり、関連部分に関する僕の仕様の理解は正しく、仕様も正しいということだ。SI-5354 によると、間違っていたのはコンパイラの実装だった。

再考「import 税のかからない implicit」

Northeast Scala Symposium 2012 もあと数ヶ月という所だけど、2011年をまとめるという形で去年のシンポジウムでの発表の一つを再考してみたい。とにかく、nescala は次から次へとクオリティの高い発表があった。これらの全ては、ここで見ることができる。Daniel の関数型のデータ構造と Janas の Akka がそれぞれ一時間のキーノートがあったこともあり、Scala コミュニティーの中に FP とアクターという二つの潮流が形成されつつあることが印象に残った（Paul がアクターのメッセージの送信には参照透過性が無いと宣言したのもヒントだったかもしれない）。また、一年のその後の予兆とも言えた Mark の sbt 0.9 のプレゼンや Nermin による Scala のパフォーマンスに関する考察もあった。しかし、僕の中で直ちにコードを変更する必要に迫られような直接的なインパクトという意味で抜きん出た発表は Josh の発表だった: Implicits without the import tax: How to make clean APIs with implicits. （import 税のかからない implicit: implict を用いていかにクリーンな API を作るか）

• ビデオ
• スライド

暗黙のパラメータ解決

Josh の発表の大きな点は、暗黙のパラメータ (implicit parmeter) はいくつものレイヤーを順番に見ていくことで解決され、ワイルドカード import は高い優先順位を占めるため、ライブラリがそれを使ってしまうとユーザがそれをオーバーライドできなくなってしまうということだった。

このポストにおいて、implicit の解決優先順位を Scala Language Specification を読んだりコードで試していくことで探検していきたい。せっかちな人のために、最終的に導きだされた優先順位を以下に示した:

• 1. Implicits with type T defined in current scope. (relative weight: 3)
• 2. Less specific but compatible view of type U defined in current scope. (relative weight: 2)
• 2-b) Implicits with type T defined in current class X’s parent trait or class X₂. (relative weight: 2)
• 3-b) Implicits with type T defined in X₂’s parent trait or class X₃. (relative weight vs 2-b: 1)
• 2-c) Implicits with type T defined in outer scope, explicit imports, wildcard imports, and implicits in package object Y. (relative weight: 2)
• 3-c) Implicits with type T defined in the package object’s parent trait or class Y₂. (relative weight vs 2-c: 1)
• 3-d) Less specific but compatible view of type U defined in parent trait or class Z. (relative weight: 1)
• 4-d) Less specific but compatible view of type U defined in Z’s parent trait or class Z₂. (relative weight vs 3-d: 0)
• 3-e) Less specific but compatible view of type U defined in outer scope, explicit imports, wildcard imports, and implicits in package object W. (relative weight: 1)
• 4-e) Less specific but compatible view of type U defined in package object W’s parent class W₂. (relative weight vs 3-e: 0)
• 5. Implicits with type T defined in the package object of T.
• 6. Implicits with type T defined in the parent trait Q₂ of package object of T.
• 5. Implicits with type T defined in the companion object of T.
• 6. Implicits with type T defined in companion object of T’s parent trait or class T₂.
• 5. Implicits with type T defined in the companion object of type constructor M[_].
• 6. Implicits with type T defined in companion object of M[_]’s parent trait or class M₂.
• 5. Implicits with type T defined in the companion object of type parameter A.
• 6. Implicits with type T defined in companion object of A’s parent trait or class A₂.
• 5. Implicits with type T defined in the companion object of compound parts R.
• 6. Implicits with type T defined in companion object of R’s parent trait or class R₂.
• 5. Implicits with type T defined in the companion object of outer type p for singleton types p.type.
• 6. Implicits with type T defined in companion object of p’s parent trait or class p₂.
• 5. Implicits with type T defined in the companion object of outer type S of type projections S#U.
• 6. Implicits with type T defined in companion object of S’s parent trait or class S₂.

the Scala Language Specification

the Scala Language Specification (pdf) はこれに関して何を言っているだろうか? p. 106:

Iterator パターンの本質

これは Scala Advent Calendar 2011 の 17日目の記事です。 specs2 の作者であり、@etorreborre としても活発に発言を続けるシドニーの強豪 Eric Torreborre さんが書いた “The Essence of the Iterator Pattern” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。

2011年6月24日 Eric Torreborre 著 2011年12月17日 e.e d3si9n 訳

去年読んだ論文で一番気に入ったのは “The Essence of the Iterator Pattern”（以下、EIP）だ。これを読んだ後で、今まで何年も使い続けてきたあるものに対する考えがガラリと変わった。それは、for ループだ。

この論文の中からいくつかのアイディアを紹介して、書かれている解法の実装方法を Scalaz っぽいコードを使って説明する。以前に関数型プログラミング、ファンクタ、モナドなどに少しでも触れたことがあれば、役立つと思う!

for ループの中身は何だ?

これが、本当に僕がハマったキッカケだ。「for ループの中身は何だ」とはどういう意味だ? 僕が何年も使ってきたこの構文に、何か魔法は入っていないだろうか?

EIP の導入部に、（C のような添字を使った for ではなく）各要素を一つづつ順に返すタイプの for ループの例がでてくる。ここでは、Scala に変身させて書くけど、考え方は一緒だ:

val basket: Basket[Fruit] = Basket(orange, apple)
var count = 0

val juices = Basket[Juice]()
for (fruit <- basket) {
  count = count + 1
  juices.add(fruit.press)
}

まず、フルーツの「コンテナ」である Basket から始める。これは、List、Tree、Map など別に何でもいい。for ループは、次に以下の 3つのことを実行する:

1. **同じ「形」**をしたコンテナを返す（ジュースも Basket であるため）。
2. 何らかの計測値を累積 (accumlate) を行う。ここでは、count 変数にフルーツの数が累積されている。
3. 要素を別の要素に投射する (map)。ここでは、フルーツを潰して果汁を得ている。

この for ループは最も複雑なものというわけでもない:

フィールドテスト: conscript, giter8, sbt-dirty-money

Scala のツールを使った、日常のコーディングでのテクニックを紹介したい。 例えば、ツールとかライブラリを開発してるとして、バグ報告を受けるとする。まず原因の分析に入る前に僕が集中することは、ユーザが使っているのと同じデータで問題を再現することだ。問題が再現できれば、次に問題を単純化して失敗する spec や機能テストに落としこむことに移行する。バグが修正されれた後で、同じセットアップを使って実際のデータでもバグが直っているかを確認することができる。

始める sbt: 公式ガイド

sbt プロジェクトからついに、公式ガイドと言える Getting Started Guide が出てきたので、翻訳しました。原文は、Heroku に Scala を載せたりなんかしてる、Typesafe 社の Havoc Pennington 氏により全て書かれています。

• 始める sbt

非公式 sbt 0.10 ガイド v2.0

version 2.0

2011年6月19日に最初のバージョンを書いた時点での僕の動機は、運良く Mark による sbt 0.10 のデモを二回も生で見れたことに触発されて（最初は northeast scala、次に scala days 2011）、sbt 0.7 から 0.10 へと皆が移行するのを手助けしたかったからだった。プラグインがそろっていなければビルドユーザが 0.10 に移行できないため、プラグインが移行への大きな妨げになるというのが大方の考えだった。そこで僕が取った戦略は、無いプラグインは自分で移植して、つまずいたらメーリングリストで質問して、結果をここでまとめるというものだった。それにより、多くのポジティブな反応があったし、数人を 0.10 へ移行する手助けにもなったと思う。だけど、後ほど明らかになったのは、僕の sbt 0.10 に関する理解は完全なものではなく、時として全く間違っており誤解を与えるものだったということだ。文責は僕にあるが、古い内容をそのまま残しておくのではなく、github に push して、新しいバージョンを作って、前へ進むことにした。プラグインの作成に関する最新の知識は Plugins Best Practices にまとめられており、大部分は Brian と Josh、ちょこっとだけ僕により書かれている。

慌てるな (don’t panic)

さっき 0.7 の世界から着陸したばっかりの君。sbt 0.10 があまりにも違うのでビックリすることだと思う。ゆっくり時間をかけて概念を理解すれば、必ず分かるようになるし、sbt 0.10 の事がきっと大好きになることを約束する。

三つの表現

sbt 0.10 とやり取りするのに三つの方法があるため、最初は混乱するかもしれない。

1. sbt 0.10 を起動時に現れるシェル。
2. build.sbt や settings 列に入る Quick Configurations DSL。
3. 普通の Scala コード、別名 Full Configuration。

それぞれの表現は別々の使用モデルに最適化している。sbt を単にプロジェクトをビルドするのに使っている場合は、ほとんどの時間を publish-local などのコマンドを使って、シェルの中で過ごすだろう。次にライブラリの依存性など基本的な設定の変更を行いたい場合、build.sbt の Quick Configurations DSL に移行する。最後に、サブプロジェクトを定義したり、プラグインを書く場合には、Full Configuration を使うことで Scala のパワーを発揮することができる。

sbt プラグインをテストする

テストの話をしよう。一度プラグインを書いてしまうと、どうしても長期的なものになってしまう。新しい機能を加え続ける（もしくはバグを直し続ける）ためにはテストを書くのが合理的だ。だけど、ビルドツールのプラグインのテストなんてどうやって書けばいいんだろう？もちろん飛ぶんだよ。

scripted test framework

sbt は、scripted test framework というものが付いてきて、ビルドの筋書きをスクリプトに書くことができる。これは、もともと 変更の自動検知や、部分コンパイルなどの複雑な状況下で sbt 自体をテストするために書かれたものだ:

ここで、仮に B.scala を削除するが、A.scala には変更を加えないものとする。ここで、再コンパイルすると、A から参照される B が存在しないために、エラーが得られるはずだ。 [中略 (非常に複雑なことが書いてある)]

scripted test framework は、sbt が以上に書かれたようなケースを的確に処理しているかを確認するために使われている。

正確には、このフレームワークは siasia として知られる Artyom Olshevskiy 氏により移植された scripted-plugin 経由で利用可能だが、これは正式なコードベースに取り込まれている。

ステップ 1: snapshot

scripted-plugin はプラグインをローカルに publish するため、まずは version を -SNAPSHOT なものに設定しよう。

ステップ 2: scripted-plugin

次に、scripted-plugin をプラグインのビルドに加える。project/scripted.sbt:

libraryDependencies <+= (sbtVersion) { sv =>
  "org.scala-sbt" % "scripted-plugin" % sv
}

以下を scripted.sbt に加える:

ScriptedPlugin.scriptedSettings

scriptedLaunchOpts := { scriptedLaunchOpts.value ++
  Seq("-Xmx1024M", "-XX:MaxPermSize=256M", "-Dplugin.version=" + version.value)
}

scriptedBufferLog := false

ステップ 3: src/sbt-test

src/sbt-test/<テストグループ>/<テスト名> というディレクトリ構造を作る。とりあえず、src/sbt-test/<プラグイン名>/simple から始めるとする。

sff4s: simple future facade for Scala

future の実装には様々なものがあるけど、標準ライブラリの中に共通の親 trait があれば、特定のプラットフォームスタックにコードを依存させずにこの概念を表現できるのにと思っていた。そう思う人が他にもいるかは分からないけど、ライブラリの作者なんかには役に立つんじゃないかな。取り敢えずこれが、sff4s を書いた動機だ。

future って何?

多分名前ぐらいは聞いたことあるかもしれないけど、一応おさらいしよう。future値（promise とも呼ばれる）は未完の計算を表現する。

• future値は未完の計算を表現する。

これがよく使われる説明だけど、それだけでは分からない。ここで言外に含まれているのは、その計算は裏で行われているということだ。それは同じコンピュータ内の別のスレッドか、別のサーバの中かもしれないし、行列待ちでまだ計算は始まってさえいないかもしれない。とにかく、計算は現在の制御フローの外で行われているということだ。

• 計算はどこか別の所で行われる。

future値のもう一つの側面は、そのうちに計算結果を得られるということだ。Scala の場合は def apply() を呼び出すなどの明示的なステップを要する。計算が未完の場合は、ブロック(block)する。つまり、計算結果が得られるまで待たされる（もしくはタイムアウトする）。

• future値から計算結果を得ることができる。

最初に future値が宣言された時には計算結果は有るかもしれないし、まだ無いかもしれない。うまくいけば、ある時点で結果が到着し、オブジェクトの内部構造が変更される。これを、future値を「解決」(resolve)したという。勝手に状態が変わるものというのはプログラミングではあまり見かけないので、少し不気味ではある。

• 計算結果を解決するための裏口がある。

これまでで、最も単純な形の future値を記述した。実際に役に立つには他の機能も必要だけど、これでも使えないことはない。ちょっと使用例をみてみよう:

val factory = sff4s.impl.ActorsFuture
val f = factory future {
  Thread.sleep(1000)
  1
}
f() // => これは 1秒間ブロックした後で 1 を返す

細かい事は気にしないで、最後の一行の振る舞いだけ見てほしい。このように、計算結果を取得することを、強要(forcing)するともいう。最小限の API は以下のようになる。

Future v0.1

abstract class Future[+A] {
  /** 計算結果を強要して無期限にブロックする */
  def apply(): A
}

Scala から使用可能な future値の実装にはいくつかあるけど、どれも一から書かれてる。上のような共通な親クラスがあれば、特定のライブラリに依存しないコードを書くことができる。

まだ来ない?

Future v0.1 に対して唯一できる事が計算結果が戻ってくるまでブロックしてしまうので、あまりにも不便だ。待つことしかできないから future を使わないほうがいい。そのため、全ての future値が提供するもう一つの機能として、計算結果の用意ができたかを確かめるノンブロッキング(non-blocking)な方法がある。これは実装によって isDone、isSet、isDefined、isCompleted などと呼ばれているが、全て同じ意味だ。今のところ、僕の好みとしては def isDefined: Boolean がいいと思う。future を概念的に Option の変数として考えることができるからだ。

モナドはメタファーではない

Scala界の関数型プログラミング一派を代表する論客の一人、@djspiewak が 2010年に書いた “Monads Are Not Metaphors” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。

2010年12月27日 Daniel Spiewak 著 2011年5月29日 e.e d3si9n 訳

僕は今、約束を破るところだ。およそ三年前、僕は絶対にモナドの記事だけは書かないと自分に約束した。既にモナドに関する記事は有り余っている。記事の数が多すぎてその多さだけで多くの人は混乱している。しかも全員がモナドに対して異なる扱い方をしているため、モナドの概念を初めて学ぼうとする者は、ブリトー、宇宙服、象、砂漠のベドウィン (訳注: アラブ系遊牧民) の共通項を探す努力をするハメになっている。

僕は、この混乱した喩え話のサーカスにわざわざもう一つ追加するようなことはしない。まず、どの喩え話も完全には正確では無い。どの喩えも全体像を伝えきれていないし、いくつかは重要な点に関して露骨に誤解を招くような内容になっている。メキシコ料理や宇宙（そら）に思いをはせることでは、絶対にモナドを理解することはできない。モナドを理解する唯一の見方は、それをありのままの姿、つまり数学的概念として見ることだ。

実戦での Scala: Cake パターンを用いた Dependency Injection (DI)

Akka の作者として益々注目を集めている Jonas Bonér が 2008年に書いた “Real-World Scala: Dependency Injection (DI)” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。

2008年10月6日 Jonas Bonér 著 2011年4月22日 eed3si9n 訳

さて、実戦での Scala シリーズ第二弾の今回は、Scala を用いた Depenency Injection (DI) の実装をみていきたい。Scala は、備わっている言語機構だけを用いても何通りかの DI を実現できる非常に豊かでディープな言語だが、必要に応じて既存の Java DI フレームワークを使うこともできる。

Triental では、一つの戦略に落ち着くまで三つの異なる方法を試した。以下のように話を進めていく。まず、現行の DI の実現方法を詳しく説明した後で、試した他の方法も簡単にカバーする。

Cake パターンを用いる

私たちが用いている現行の戦略は、いわゆる Cake パターンに基づいている。このパターンは、Martin Odersky の論文 Scalable Component Abstractions において、Ordersky と彼のチームが Scala のコンパイラを構成した方法として最初に発表された。このパターンがどのようにして DI を実現するのかということを日本語で説明する事を試みるよりも、（私たちの実際に使っているコードに大まかに基づいた）愚直なサンプルコードをみてみよう。

注意: 順を追って、最終バージョンに向けてリファクタリングしながら説明していくので、最終バージョンを読んで理解するまでは、「ダメじゃん!」と叫ぶのは待ってほしい（もちろん、読了後にどうしてもと言うなら批判、賞賛、意見、アイディアなどを送ってもいい）。また、このサンプルコードは、このようなサンプルの例にもれず、非常に複雑な方法で取るに足りない事を行っているようにみえるが、我慢して大規模システムでの実際のサービスを想像して、どのように応用できるかを想像して欲しい。

まずは、UserRepository (DAO、Data Access Object) を実装しよう。

// 実際の永続化は何もしていなくて、画面にユーザを表示するだけのダミー。 
class UserRepository {  
  def authenticate(user: User): User = {   
    println("authenticating user: " + user)  
    user  
   }  
  def create(user: User) = println("creating user: " + user)  
  def delete(user: User) = println("deleting user: " + user)  
}

trait インターフェイスとその実装に分けて実装することもできたが、話を簡単にするために、敢えてここではそうしなかった。

Scala と Json で tweed を織る

次々とヤバいコードを紡ぎ出し NY Scala シーンの中心的存在であり続ける @n8han が二年前に書いた “Weaving tweed with Scala and Json” を翻訳しました。翻訳の公開は本人より許諾済みです。翻訳の間違い等があれば遠慮なくご指摘ください。

2009年5月27日 n8han 著 2011年1月2日 eed3si9n 訳

抽出子は、Programming in Scala の 24章にのみ記述されている Scala の秘密機能で、この春の大ヒットだ。今までは皆 case Some(thing) => kerpow(thing) で満足だったのが、今では抽出子を書けなければ #scala freenode にも入れてもらえない。ズルをすれば Scala チャンネルの硬派な常連たちは君のコンピュータをハックして驚くほど馬鹿げたドールハウスを連続再生して（ただし混浴シャワーシーンを除く）、番組の「アクティブ」のように意味のあるタイピングを諦めなければいけない。

訳注。以下 Draco より抜粋 ロッサム・コーポレーションは人間の人格、経験をすべて消し、新しい人格を植え付ける技術を開発した。彼らはこの技術を用いて、戦闘用の人形アクティブを生み出した。 人形たちはドールハウスという施設で生活している。誰かの人格を移植され、任務に挑む。 アクティブの一人、エコーは記憶のリライト中にエラーが起こり、完全には記憶が消されていなかった。

この抽出子はちょっとチクっとしますからね

命からがら逃げ出した僕は抽出子をありとあらゆる状況に適用するよう努めた。例えば、JavaScript インタプリタが理解できるお洒落な文字列、Json オブジェクトだ。抽出子を使えば case 構文でこのように処理することができる:

import dispatch.json.Js
val echo = Js("""{"acting": "無表情で前を見ている"}""")
object Echo extends Js { val acting = 'acting ? str }
echo match {
  case Echo.acting(hmm) => hmm
  case _ => "pshaw"
}

res0: String = staring blankly ahead

Symbol 'acting に対して ? を呼び出すことで抽出子が作成される。Symbol には ? メソッドはないが暗黙の変換でそれをもつオブジェクトに変換されている。Echo　はいつも演技してるということが分かっているので、この抽出子を使って直接代入することもできる:

IntelliJ IDEA のための Twilight

Scala をやりながら他の IDE も試しましたが、結局 TextMate に戻っています。 今回巷で話題の IntelliJ IDEA に便乗するにあたって、Twilight theme を作りました。

型クラスによる XML データバインディング

結局の所，scalaxb のユーザはエンティティ・オブジェクトが表現する現実の問題に興味があるのであって，それがどう XML に永続化されるかといったことではない．だから，いつかデータバインディングの実装をシングルトン/コンパニオン・オブジェクトから追い出さなければいけないことは分かっていた．つい最近までデータバインディングの実装は以下のように生成されていた:

object Address extends rt.ElemNameParser[Address] {
  val targetNamespace = "http://www.example.com/IPO"

  def parser(node: scala.xml.Node): Parser[Address] =
    ...

  def toXML(__obj: Address, __namespace: String, __elementLabel: String, __scope: scala.xml.NamespaceBinding): scala.xml.NodeSeq =
    ...
}

つまり，scalaxb は Address そのものとは関係の無い XML データバインディングのために一等地をハイジャックしてしまったのだ．

adapter

まず最初に以下のような adapter オブジェクトに追い出すことを考えた:

object DefaultXMLAdapter {
  object AddressAdapter extends rt.ElemNameParser[Address] {
    val targetNamespace = "http://www.example.com/IPO"

    def parser(node: scala.xml.Node): Parser[Address] =
      ...

    def toXML(__obj: Address, __namespace: String, __elementLabel: String, __scope: scala.xml.NamespaceBinding): scala.xml.NodeSeq =
      ...
  }
}

この方法にはいくつかの問題がある．まず，scalaxb のランタイムである DataRecord が，今まではコンパニオン・オブジェクトの暗黙性を使ってたどっていた toXML にたどり着けないということだ．コンパニオン・オブジェクトの興味深い一面として「コンパイラは，暗黙 (implicit) の定義を変換元の型と変換先の型のコンパニオン・オブジェクトにも探しにいく」(Programming in Scala, p. 441) というものがある．

第二の問題は，アイデンティティー問題だ．ユーザのコードの邪魔にならないようにしようとしているのに，Address オブジェクトのためには DefeaultXMLAdapter.AddressAdapter，Item のためには DefeaultXMLAdapter.ItemAdapterなどと，　かえって目に障るものを導入してしまった．ユーザが知っている必要があるのは Address が XML に変換できるという事実だけあって，それがどう行われているかというのは余計な詳細でしかない．

第三の問題として，拡張性の問題がある．例えば，Address を定義する ipo.xsd と，Address を使う purchaseReport要素を定義する report.xsd の二つのスキーマがあるとする．問題は，report.DefaultXMLAdapter.PurchaseReportAdapter は ipo.DefaultXMLAdapter.AddressAdapter を参照するため，ipo.DefaultXMLAdapter を拡張してカスタムのデータバインディングをすることができないということだ．

sjson: Scala の型クラスによる JSON シリアライゼーション

Debasish Ghosh さん (@debasishg) の “sjson: Now offers Type Class based JSON Serialization in Scala” を翻訳しました． 元記事はこちら: http://debasishg.blogspot.com/2010/07/sjson-now-offers-type-class-based-json.html (翻訳の公開は本人より許諾済みです) 翻訳の間違い等があれば遠慮なくご指摘ください

長い間 sjson のシリアライゼーション API はリフレクションに依存するものだった．この方法の長所としては，縁の下ではリフレクションによる実装が頑張っていても API は使いやすくすることができたということだ．

しかし，JSON 構造と Scala のオブジェクトでは型情報の豊かさに大きな違いがあることを忘れてはいけない．Scala から JSON にいくときに何らかの形で型情報をシリアライゼーションプロトコルの一部として保存しないかぎり，可逆変換させるのは場合によってはとてもトリッキーで難しいことになる．特に JVM では type erasure のせいで JSON構造にシリアル化した Scala オブジェクトの中には元に戻すのがほぼ不可能なものもあるだろう．

ver 0.7 より sjson は元のものに加えリフレクションを使わない JSON シリアライゼーションプロトコルを用意した．これはユーザが任意のオブジェクトから JSON へシリアル化する自分のプロトコルを規定できるようになった．リフレクションによる JSON シリアライゼーションではアノテーションで行っていたものをカスタムプロトコルを自分で実装することで実現することができる．

sjons の型クラスによるシリアライゼーションは David MacIver による素晴らしい sbinary (現在は Mark Harrah によりメンテされいる) にインスパイアされており，同じプロトコルを使いまた実装レベルでも色々と盗ませてもらった．

型クラスの基礎的概念への入門，Scala での実装，そして型クラスを使ったシリアライゼーションプロトコルが Scala でどう設計できるかについては，数週間前に書いた以下の blog 記事を参照してほしい:

• Scala Implicits: 型クラス襲来
• Scala 型クラスへのリファクタリング

組み込み型の JSON シリアライゼーション

これは sjson でデフォルトのシリアライゼーションプロトコルを使った REPL セッションの一例だ…

Scala Implicits: 型クラス、襲来

Debasish Ghosh さん (@debasishg) の “Scala Implicits : Type Classes Here I Come” を翻訳しました． 元記事はこちら: http://debasishg.blogspot.com/2010/06/scala-implicits-type-classes-here-i.html (翻訳の公開は本人より許諾済みです) 翻訳の間違い等があれば遠慮なくご指摘ください．

先日 Twitter 上で Daniel と Scala での型クラスについて論議していると，突然このトピックに関する書きかけだった記事を発見した．これを読んでもあなたは特に目新しい事を発見するわけではないが，型クラスに基づいた思考はあなたの設計の幅に価値を与えることができると思う．この記事を書き始めたのはしばらく前に設計の直交性についての記事 (原文)を公開したときのことだ．

まずは GoF の Adapter パターンから始めよう．委譲型の Adapter はよく勧められる合成(composition)というテクニック用いて抽象体(abstraction)¹どうしをバインドする．

設計の直交性のときと同じ例を使うと，

case class Address(no: Int, street: String, city: String, 
  state: String, zip: String)

これを LabelMaker というインターフェイスに適合させたいとする．つまり，我々は Address オブジェクトを LabelMaker として使いたい．

trait LabelMaker[T] {
  def toLabel(value: T): String
}

インターフェイス変換を行うアダプターは…

// Adapter クラス
case class AddressLabelMaker extends LabelMaker[Address] {
  def toLabel(address: Address) = {
    import address._
    "%d %s, %s, %s - %s".format(no, street, city, state, zip)
  }
}

// この Adapter は Address オブジェクトに LabelMaker のインターフェイスを提供する．
AddressLabelMaker().toLabel(Address(100, "Monroe Street", "Denver", "CO", "80231"))

さて，上の設計で我々が副次的に導入してしまった複雑さはなんだろう？