昨日は、何故か早朝に目が覚めて @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 {}
}

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

背景

Mark 曰く:

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

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

一見普通の演算でもいかに高速化できるかをいつも考えて発表してる奇才 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

警告: この 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 によって構成される。

去年に書いた Scala で書く tetrix を @n8han の Pamflet を使って html5 book にリビルドした。git 履歴をコミット毎にたどって使われているライブラリやツール群を 2013年時点で最先端のものに全てアップグレードした。ビルドは sbt 0.13.0 を使って build.sbt のみでマルチプロジェクトを行い、Scala は 2.10.2、全ての specs2 スペックは補間を使い、pfn/android-sdk-plugin 1.0.6 を用いて Akka 2.2.1 を Android に搭載した。

さらに Android での tetrix のデバッグと調整のために新たに 13日目を書き下ろした。

• Scala で書く tetrix

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

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

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

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

オブジェクトとは何か?

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

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

sbt 0.13.0 の変更点を訳しました。
マクロを多用することで、DSL が一気にスッキリするみたいです。

概要

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

• 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 になった。

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 訳

談: こんにちは。ご招待いただきありがとうございます。
聞く所によると RailsConf はいつもコミュニティーからかなり外れた人を選ぶらしく、今回は僕ということになりました。
僕の電話ボックスは外に駐車してあります。(会場、笑)
だけど、今日は言語の壁を越える話題を持ってきました。Simplicity、つまりシンプルさについてです。

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) と呼ぶことにする。