猫番 — Monad

Monad

先ほど Cats はモナド型クラスを FlatMap と Monad の2つに分けると書いた。この FlatMap-Monad の関係は、Apply-Applicative の関係の相似となっている:

@typeclass trait Monad[F[_]] extends FlatMap[F] with Applicative[F] {
  ....
}

Monad は　FlatMap に pure を付けたものだ。Haskell と違って Monad[F] は Applicative[F] を拡張するため、return と pure と名前が異なるという問題が生じていない。

綱渡り

Derived from Bello Nock's Sky Walk by Chris Phutully

LYAHFGG:

さて、棒の左右にとまった鳥の数の差が3以内であれば、ピエールはバランスを取れているものとしましょう。例えば、右に1羽、左に4羽の鳥がとまっているなら大丈夫。だけど左に5羽目の鳥がとまったら、ピエールはバランスを崩して飛び降りる羽目になります。

本の Pole の例題を実装してみよう。

scala> import cats._, cats.data._, cats.implicits._
import cats._
import cats.data._
import cats.implicits._
scala> type Birds = Int
defined type alias Birds
scala> case class Pole(left: Birds, right: Birds)
defined class Pole

Scala ではこんな風に Int に型エイリアスを付けるのは一般的じゃないと思うけど、ものは試しだ。landLeft と landRight をメソッドをとして実装したいから Pole は case class にする:

scala> :paste
// Entering paste mode (ctrl-D to finish)
case class Pole(left: Birds, right: Birds) {
  def landLeft(n: Birds): Pole = copy(left = left + n)
  def landRight(n: Birds): Pole = copy(right = right + n)
}

// Exiting paste mode, now interpreting.
defined class Pole

OO の方が見栄えが良いと思う:

scala> Pole(0, 0).landLeft(2)
res0: Pole = Pole(2,0)
scala> Pole(1, 2).landRight(1)
res1: Pole = Pole(1,3)
scala> Pole(1, 2).landRight(-1)
res2: Pole = Pole(1,1)

連鎖も可能:

scala> Pole(0, 0).landLeft(1).landRight(1).landLeft(2)
res3: Pole = Pole(3,1)
scala> Pole(0, 0).landLeft(1).landRight(4).landLeft(-1).landRight(-2)
res4: Pole = Pole(0,2)

本が言うとおり、中間値で失敗しても計算が続行してしまっている。失敗を Option[Pole] で表現しよう:

scala> :paste
// Entering paste mode (ctrl-D to finish)
case class Pole(left: Birds, right: Birds) {
  def landLeft(n: Birds): Option[Pole] =
    if (math.abs((left + n) - right) < 4) copy(left = left + n).some
    else none[Pole]
  def landRight(n: Birds): Option[Pole] =
    if (math.abs(left - (right + n)) < 4) copy(right = right + n).some
    else none[Pole]
  }

// Exiting paste mode, now interpreting.
defined class Pole
scala> Pole(0, 0).landLeft(2)
res5: Option[Pole] = Some(Pole(2,0))
scala> Pole(0, 3).landLeft(10)
res6: Option[Pole] = None

flatMap もしくはシンボル使ったエイリアスである >>= を使って landLeft と landRight をチェインする:

scala> val rlr = Monad[Option].pure(Pole(0, 0)) >>= {_.landRight(2)} >>=
  {_.landLeft(2)} >>= {_.landRight(2)}
rlr: Option[Pole] = Some(Pole(2,4))

モナディックチェインが綱渡りのシミュレーションを改善したか確かめる:

scala> val lrlr = Monad[Option].pure(Pole(0, 0)) >>= {_.landLeft(1)} >>=
  {_.landRight(4)} >>= {_.landLeft(-1)} >>= {_.landRight(-2)}
lrlr: Option[Pole] = None

うまくいった。この例はモナドが何なのかをうまく体現しているので、じっくり考えて理解してほしい。

まず、pure が Pole(0, 0) をデフォルトのコンテクストで包む: Pole(0, 0).some
次に、Pole(0, 0).some >>= {_.landLeft(1)} が起こる。これは Some値なので、Pole(0, 0) に _.landLeft(1) が適用されて、Pole(1, 0).some が返ってくる。
次に、Pole(1, 0).some >>= {_.landRight(4)} が起こる。結果は Pole(1, 4).some。これでバランス棒の左右の差の最大値となった。
Pole(1, 4).some >>= {_.landLeft(-1)} が発生して、none[Pole] が返ってくる。差が大きすぎて、バランスが崩れてしまった。
none[Pole] >>= {_.landRight(-2)} は自動的に none[Pole] となる。

モナディックな関数をチェインでは、一つの関数の効果 (effect) が次々と渡されていくのが見えると思う。

ロープの上のバナナ

LYAHFGG:

さて、今度はバランス棒にとまっている鳥の数によらず、いきなりピエールを滑らせて落っことす関数を作ってみましょう。この関数を banana と呼ぶことにします。

以下が常に失敗する banana だ:

scala> :paste
// Entering paste mode (ctrl-D to finish)
case class Pole(left: Birds, right: Birds) {
  def landLeft(n: Birds): Option[Pole] =
    if (math.abs((left + n) - right) < 4) copy(left = left + n).some
    else none[Pole]
  def landRight(n: Birds): Option[Pole] =
    if (math.abs(left - (right + n)) < 4) copy(right = right + n).some
    else none[Pole]
  def banana: Option[Pole] = none[Pole]
}

// Exiting paste mode, now interpreting.
defined class Pole
scala> val lbl = Monad[Option].pure(Pole(0, 0)) >>= {_.landLeft(1)} >>=
  {_.banana} >>= {_.landRight(1)}
lbl: Option[Pole] = None

LYAHFGG:

ところで、入力に関係なく既定のモナド値を返す関数だったら、自作せずとも >> 関数を使うという手があります。

以下が >> の Option での振る舞い:

scala> none[Int] >> 3.some
res7: Option[Int] = None
scala> 3.some >> 4.some
res8: Option[Int] = Some(4)
scala> 3.some >> none[Int]
res9: Option[Int] = None

banana を >> none[Pole] に置き換えてみよう:

scala> val lbl = Monad[Option].pure(Pole(0, 0)) >>= {_.landLeft(1)} >>
  none[Pole] >>= {_.landRight(1)}
<console>:22: error: missing parameter type for expanded function ((x$1: <error>) => x$1.landLeft(1))
       val lbl = Monad[Option].pure(Pole(0, 0)) >>= {_.landLeft(1)} >>
                                                     ^

突然型推論が崩れてしまった。問題の原因はおそらく演算子の優先順位にある。 Programming in Scala 曰く:

The one exception to the precedence rule, alluded to above, concerns assignment operators, which end in an equals character. If an operator ends in an equals character (=), and the operator is not one of the comparison operators <=, >=, ==, or !=, then the precedence of the operator is the same as that of simple assignment (=). That is, it is lower than the precedence of any other operator.

注意: 上記の記述は不完全だ。代入演算子ルールのもう1つの例外は演算子が === のように (=) から始まる場合だ。

>>= (bind) が等号で終わるため、優先順位は最下位に落とされ、({_.landLeft(1)} >> (none: Option[Pole])) が先に評価される。いくつかの気が進まない回避方法がある。まず、普通のメソッド呼び出しのようにドットと括弧の記法を使うことができる:

scala> Monad[Option].pure(Pole(0, 0)).>>=({_.landLeft(1)}).>>(none[Pole]).>>=({_.landRight(1)})
res10: Option[Pole] = None

もしくは優先順位の問題に気付いたなら、適切な場所に括弧を置くことができる:

scala> (Monad[Option].pure(Pole(0, 0)) >>= {_.landLeft(1)}) >> none[Pole] >>= {_.landRight(1)}
res11: Option[Pole] = None

両方とも正しい答が得られた。

for 内包表記

LYAHFGG:

Haskell にとってモナドはとても便利なので、モナド専用構文まで用意されています。その名は do 記法。

まずは入れ子のラムダ式を書いてみよう:

scala> 3.some >>= { x => "!".some >>= { y => (x.show + y).some } }
res12: Option[String] = Some(3!)

>>= が使われたことで計算のどの部分も失敗することができる:

scala> 3.some >>= { x => none[String] >>= { y => (x.show + y).some } }
res13: Option[String] = None
scala> (none: Option[Int]) >>= { x => "!".some >>= { y => (x.show + y).some } }
res14: Option[String] = None
scala> 3.some >>= { x => "!".some >>= { y => none[String] } }
res15: Option[String] = None

Haskell の do 記法のかわりに、Scala には for 内包表記があり、これらは似た機能を持つ:

scala> for {
         x <- 3.some
         y <- "!".some
       } yield (x.show + y)
res16: Option[String] = Some(3!)

LYAHFGG:

do 式は、let 行を除いてすべてモナド値で構成されます。

これは for では微妙に違うと思うけど、また今度。

帰ってきたピエール

LYAHFGG:

ピエールの綱渡りの動作も、もちろん do 記法で書けます。

scala> def routine: Option[Pole] =
         for {
           start <- Monad[Option].pure(Pole(0, 0))
           first <- start.landLeft(2)
           second <- first.landRight(2)
           third <- second.landLeft(1)
         } yield third
routine: Option[Pole]
scala> routine
res17: Option[Pole] = Some(Pole(3,2))

yield は Option[Pole] じゃなくて Pole を受け取るため、third も抽出する必要があった。

LYAHFGG:

ピエールにバナナの皮を踏ませたい場合、do 記法ではこう書きます。

scala> def routine: Option[Pole] =
         for {
           start <- Monad[Option].pure(Pole(0, 0))
           first <- start.landLeft(2)
           _ <- none[Pole]
           second <- first.landRight(2)
           third <- second.landLeft(1)
         } yield third
routine: Option[Pole]
scala> routine
res18: Option[Pole] = None

パターンマッチングと失敗

LYAHFGG:

do 記法でモナド値を変数名に束縛するときには、let 式や関数の引数のときと同様、パターンマッチが使えます。

scala> def justH: Option[Char] =
         for {
           (x :: xs) <- "hello".toList.some
         } yield x
justH: Option[Char]
scala> justH
res19: Option[Char] = Some(h)

do 式の中でパターンマッチが失敗した場合、Monad 型クラスの一員である fail 関数が使われるので、異常終了という形ではなく、そのモナドの文脈に合った形で失敗を処理できます。

scala> def wopwop: Option[Char] =
         for {
           (x :: xs) <- "".toList.some
         } yield x
wopwop: Option[Char]
scala> wopwop
res20: Option[Char] = None

失敗したパターンマッチングは None を返している。これは for 構文の興味深い一面で、今まで考えたことがなかったが、言われるとなるほどと思う。

Monad則

モナドには 3つの法則がある:

左単位元 (left identity): (Monad[F].pure(x) flatMap {f}) === f(x)
右単位元 (right identity): (m flatMap {Monad[F].pure(_)}) === m
結合律 (associativity): (m flatMap f) flatMap g === m flatMap { x => f(x) flatMap {g} }

LYAHFGG:

第一のモナド則が言っているのは、return を使って値をデフォルトの文脈に入れたものを >>= を使って関数に食わせた結果は、単にその値にその関数を適用した結果と等しくなりなさい、ということです。

これを Scala で表現すると、

scala> assert { (Monad[Option].pure(3) >>= { x => (x + 100000).some }) ===
         ({ (x: Int) => (x + 100000).some })(3) }

LYAHFGG:

モナドの第二法則は、>>= を使ってモナド値を return に食わせた結果は、元のモナド値と不変であると言っています。

scala> assert { ("move on up".some >>= {Monad[Option].pure(_)}) === "move on up".some }

LYAHFGG:

最後のモナド則は、>>= を使ったモナド関数適用の連鎖があるときに、どの順序で評価しても結果は同じであるべき、というものです。

scala> Monad[Option].pure(Pole(0, 0)) >>= {_.landRight(2)} >>= {_.landLeft(2)} >>= {_.landRight(2)}
res23: Option[Pole] = Some(Pole(2,4))
scala> Monad[Option].pure(Pole(0, 0)) >>= { x =>
       x.landRight(2) >>= { y =>
       y.landLeft(2) >>= { z =>
       z.landRight(2)
       }}}
res24: Option[Pole] = Some(Pole(2,4))

4日目の Monoid則を覚えていると、見覚えがあるかもしれない。それは、モナドはモノイドの特殊な形だからだ。

「ちょっと待て。Monoid は A (別名 *) のカインドのためのものじゃないのか?」と思うかもしれない。確かにその通り。そして、これが「モノイド」と Monoid[A] の差でもある。 Haskell スタイルの関数型プログラミングはコンテナや実行モデルを抽象化することができる。圏論では、モノイドといった概念は A、F[A]、F[A] => F[B] といった色んなものに一般化することができる。「オーマイガー。法則多杉」と思うよりも、多くの法則はそれらをつなぐ基盤となる構造があるということを知ってほしい。

Discipline を使った Monad則の検査はこうなる:

scala> import cats._, cats.data._, cats.implicits._, cats.laws.discipline.MonadTests
import cats._
import cats.data._
import cats.implicits._
import cats.laws.discipline.MonadTests

scala> val rs = MonadTests[Option].monad[Int, Int, Int]
rs: cats.laws.discipline.MonadTests[Option]#RuleSet = cats.laws.discipline.MonadTests$$anon$2@35e8de37

scala> rs.all.check
+ monad.applicative homomorphism: OK, passed 100 tests.
+ monad.applicative identity: OK, passed 100 tests.
+ monad.applicative interchange: OK, passed 100 tests.
+ monad.applicative map: OK, passed 100 tests.
+ monad.apply composition: OK, passed 100 tests.
+ monad.covariant composition: OK, passed 100 tests.
+ monad.covariant identity: OK, passed 100 tests.
+ monad.flatMap associativity: OK, passed 100 tests.
+ monad.flatMap consistent apply: OK, passed 100 tests.
+ monad.invariant composition: OK, passed 100 tests.
+ monad.invariant identity: OK, passed 100 tests.
+ monad.monad left identity: OK, passed 100 tests.
+ monad.monad right identity: OK, passed 100 tests.

Next Page ❧ List データ型

猫番

Monad

綱渡り

ロープの上のバナナ

for 内包表記

帰ってきたピエール

パターンマッチングと失敗

Monad則

Contents