sbt 0.13.0 の変更点

in

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 がプロジェクトのベースディレクトリをカレント・ワーキング・ディレクトリとして用いるようにした。
  • compileInputsCompile ではなく (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、つまりシンプルさについてです。

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

in

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

scopt 3.0

in

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個のメソッドがあった: onIntonDoubleonBooleanon、それからもう一つオーバーロードされた on。重なる開発の結果 scopt2 は opt のオーバーロードが 6つ、intOptdoubleOptbooleanOptkeyValueOptkeyIntValueOptkeyDoubleValueOptkeyBooleanValueOpt それぞれに 4つづつのオーバーロードが蓄積された。合計 34 ものメソッドだ! これらのオーバーロードは省略可能な頭文字や値の名前のために僕が追加したものだから、自分以外に責めようが無い。これ以上の拡張は考えられなかった。

Dispatch プラグインの書き方

in

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 プラグインの書き方を解説していく。

working on your own twitter bot?

独習 Scalaz、html5 book 版

in

Scalaz 7.0 がリリースされた。読みやすさのためのと目次のために、独習 Scalaz シリーズを @n8han の Pamflet を使って html5 book化した:

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

もう一ヶ月経つけど 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 を聴いてたら、開催地が欧米圏に偏ってるから次あたり日本とかアジア圏なんてどうだろうって話が出てた。コミュニティが声出せば誘致もありえるかも

抽象的な Future

in

これは 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 を置き換える予定のものだ)。これは計算のステップを順序付けするための柔軟な方法を提供することで、本稿が注目するモナディック合成の一面を体現する。

Func を使った数独

in

これは 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 の型クラスインスタンスには既に productcompose が含まれており、また 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 を返す関数を構築するだけよくて、型レベルでの合成は自動的に行われる。

独習 Scalaz: 18日目

in

更新された html5版があるので、よろしくお願いします。

17日目は、副作用を抽象化する方法としての IO モナドと、ストリームを取り扱うための Iteratee をみて、シリーズを終えた。

Func

Applicative 関数の合成を行うより良い方法を引き続き試してみて、AppFunc というラッパーを作った:

val f = AppFuncU { (x: Int) => x + 1 }
val g = AppFuncU { (x: Int) => List(x, 5) }
(f @&&& g) traverse List(1, 2, 3)
Syndicate content