プログラミングにおいて、レンズ〈lens〉と呼ばれる構造が使われる機会が増えているようです。古典的なレンズが幾つかの方向に一般化されていて、「レンズってなに?」と聞かれても答えにくい状況になっています。
一番簡単な(と僕が思っている)ストレージの例からはじめて、具象レンズを導入し、それらのあいだの関係を調べます。記述と計算にストリング図を使用します。
内容:
シリーズ目次(リンク):
- 圏論的レンズ 最初の一歩: ストリング図を中心に(この記事)
- 圏論的レンズ 2: 具象オプティック
- 圏論的レンズ 訂正と補足: 具象レンズ=具象オプティック
- 圏論的レンズ 3: レンズ/オプティックのための描画法
- 圏論的レンズ 4: テレオロジー圏
- 圏論的レンズ 5: オプティック構成とテレオロジー圏
- 圏論的レンズ 6: 丹原/ペイストロ/ストリート随伴系
関連する記事:
元祖レンズ
歴史的な経緯はまったく調べてないので、ほんとに“元祖”かどうかは定かでないのですが、便宜上、以下のように定義される構造を元祖レンズ〈original lens〉と呼ぶことにします。
レンズとは、get と put (または view と update)と呼ばれる2つの関数の組である。
レンズの入門には、たいてい上のように書いてあります。集合 はファイルやデータベースのようなストレージ(の状態の型)を表し、集合 は何らかの値(の型)を表すと考えましょう。get は値の取得、put はストレージの更新ですね。
ストレージだと考えると、get/put は何らかの法則に従うだろうと予想できます。実際、次のような法則があります。
- put-get 法則:
- get-put 法則:
- put-put 法則:
これらの法則を満たすレンズは有法則レンズ〈lawful lens〉と呼びます。最初の2つの法則を満たすレンズを良振る舞いレンズ〈well-behaved lenses〉、3つの法則全部を満たすレンズを最良振る舞いレンズ〈very well-behaved lenses〉と呼ぶこともあります*1。
一方、何の法則も考えずに get と put の組だけ考えているときは無法則レンズ〈lawless lens〉と呼びます。
無法則レンズのほうが簡単なので、無法則レンズをベースに一般化して、必要に応じて法則性を入れるというアプローチが普通のようです。
実際のストレージのモデルとしては有法則レンズが適切ですが、ここでは法則性は無視した無法則レンズを考えます。そのほうが簡単ですからね。なので、以下単にレンズと言ったら、それは無法則レンズのことです。
元祖レンズの圏
元祖レンズ(無法則レンズなので get と put の組)は結合〈合成 | compose〉することができます。この結合演算によって、元祖レンズは全体として圏を形成します。
圏の記法と合うように、ひとつの元祖レンズを 、もうひとつの元祖レンズを のように書きます。もう少し詳しく書くと:
説明:
- 元祖レンズ のgetパートを 、putパートを と書く。
- 元祖レンズ のgetパートは、 という集合圏の射、つまり写像。
- 元祖レンズ のputパートは、 という集合圏の射、つまり写像。
- 元祖レンズの圏 において、元祖レンズ のプロファイル(域と余域)は 、つまり、見かけ上はgetパートと同じプロファイル。
- に関しても同様。
念の為に、圏 の対象類とホムセットを定義しておきます。
圏になるためには、射の結合と恒等射が必要です。それは以下のように定義します。定義において、集合圏 の結合/恒等と区別するために、元祖レンズの圏 の結合/恒等は記号 を使います。
ここで、 は集合圏の対角射、 は集合圏の第ニ射影です。
この定義で、元祖レンズの結合 のputバートが複雑に見えて鬼門かも知れません。ストリング図を描いてみましょう。結合の方向が上から下、直積の方向が左から右です。
この図を見ながらゆっくりと考えてみましょう。
結合 のputバート〈updateパート〉がやるべきことは、 のストレージ状態を、 の値を使って更新することです。そのためにまず、 から を使って の値を取り出します。取り出した の値は の状態の一部であり再びストレージ状態とみなせるとします。
取り出した結果である の状態は の値で更新できますから、 を使って更新しましょう。そしてさらに、更新済みの の状態(値ともみなせる)をもとの に反映させる必要があります。それには、 を使えばいいのです。
以上の手順が の定義を与えます。 のストレージ状態は の入力としても の入力としても使われるのでコピーする必要があります。コピーには対角射 (図ではワイヤーの分岐)が使われます。
ストレージ状態をgetパートを使って値として取り出すのですが、取り出した値がまたストレージ状態とみなせるところがキモです。
元祖レンズ達はホントに圏なのか?
前節で、圏 の対象類、ホムセット、結合、恒等が定義できました。素材はちゃんと揃っています。しかし、圏であるためには、圏としての法則を満たす必要があります。それら“圏の法則”は次のものです。
これらの法則が成立するかどうかは、射(元祖レンズ)のgetパートとputパートをそれぞれ見ていけばいいのですが、一番面倒そうなのは、結合律〈associative law〉のputパートでしょう。そこだけ書き出してみます。
これを示すにも、ストリング図を使うのが便利です。たまたま今週、ストリング図の記事を書いたので、そこで紹介した描画法を使います。
getパートは丸、putパートは四角で、 はそれぞれ塗りパターン「ベタ塗り、斜線網掛け、砂目網掛け」で区別します。ワイヤーへのラベリングはほとんど省略します。
示すべき等式を絵に描くと次のようになります。
上記の等式を示すために本質的に必要なことは次の等式です。
この等式は、対角射〈コピー射〉の余結合律と、対角射に沿って射もコピーされること*2から出ます(下図参照)。
恒等射の単位律はもっと簡単に証明できます。
Webサーバーモデル
前節の元祖レンズの説明では3種の記述方法を使いました。
- ストレージ(ファイルやデータベースのようなデータ格納媒体)を引き合いに出した比喩的説明。「元祖レンズはストレージだと考えよう」はメンタルモデル(心にいだくイメージ)の話です。
- 集合圏(対象は集合、射は写像)における形式的な定義。
- ストリング図を使った視覚的表現。
これから元祖レンズを少し一般化した具象レンズ〈concrete lens〉を導入するのですが、圏論を使った形式的定義にはちょっと準備が必要なのでそれは省略します。が、ストリング図を使った表現は紹介します。まず最初はメンタルモデルの話 -- Webサーバーの話から始めます。
Webの通信に使われているHTTPプロトコルでは、リクエストとレスポンスの区別があります。インターネットと向き合っているフロントのサーバーがリクエストを受け取り、それをバックエンド(アップストリーム)に中継するとしましょう。このとき、HTTPリクエスト・データを加工してバックエンドに対するリクエストを作ります。また、バックエンドから戻ってきたレスポンス・データも加工してインターネットに送り出すとします。
HTTPリクエストのデータ型を 、バックエンドへのリクエストのデータ型を 、バックエンドからのレスポンスのデータ型を 、HTTPレスポンスのデータ型を とすると、次のような絵が描けます。
上段のリクエストは左から右に向かい、下段のレスポンスは右から左に向かいます。 はリクエストを加工する関数、 はレスポンスを加工する関数です。
バックエンドからのレスポンスを加工するとき、もとのHTTPリクエストのデータも必要なときがあります。そんなときは、元リクエストを一時的に保存しておいて、戻り(バックエンドからのレスポンス)を加工するときに使用します。そんな状況を絵に描くと次のようになります。
この絵で表されるリクエスト処理/レスポンス処理を一塊〈ひとかたまり〉にして、Webサーバー処理のコンポネント(機能的単位)と考えましょう。コンポネントは、2つの写像〈関数〉 の組で決まります。それぞれの写像のプロファイルを書けば:
このコンポネントは、多段階に繋ぐことができます。 と を繋いだ絵は次のようになります。ここでは、 はベタ塗り、 は斜線網掛けで描いています。
繋いだ複合コンポネントを と書くことにすると、演算 が圏の結合になることは(直感的には)明らかでしょう。次のようなコンポネントが恒等射になります。
点線の丸は恒等射 を表し、点線の四角は第二射影 を表します。
具象レンズ
前節でインフォーマルに導入された“コンポネント”が具象レンズ〈concrete lens〉*3です。Webサーバー・コンポネントの例え話はともかくとしして、ストリング図による記述は十分に正確です。正確なんですが、その解釈には若干高度な圏論的道具が必要になるのです。
元祖レンズのメンタルモデルであるストレージと、具象レンズのメンタルモデルであるWebサーバー・コンポネントはだいぶ違いがありますが、実は、抽象的レベルでは同じ概念になります(次節で述べる)。ただし、具象レンズのほうが少しだけ一般化しています。
具象レンズを構成する関数を再掲すると:
一方、元祖レンズを構成する関数は:
そうです; 具象レンズにおいて と置けば元祖レンズになります。
元祖レンズの圏の対象は単一の集合でしたが、具象レンズの圏では対象が集合のペアになります。具象レンズ のプロファイルは次のように書けます。 は具象レンズの圏です。
具象レンズのリクエストパート 、レスポンスパート は例え話に由来する記法で、具象レンズの記述には次の記法が多く用いられます。
これは記号の乱用で、紛らわしくて僕は嫌いです。ここでは、以下の記法にします。
具象レンズ の向きは の向きと同じなので、 を順行パート〈forward part〉、逆向きになる を逆行パート〈backward part〉と呼びます。具象レンズは互いに逆方向な2つのパートを持ちます。
元祖レンズでは、順行パートをgetパート、逆行パートをputパートと呼んでいたわけです。
元祖レンズと具象レンズ
元祖レンズと具象レンズでは、例え話に使った素材(ストレージとWebサーバー・コンポネント)も違うし、ストリング図の見た感じも随分と違います。しかし、これらは同じ概念なのです。そのことをストリング図の変形で示してみます。
Webサーバー・コンポネントをモデルにした具象レンズのストリング図から、ストレージをモデルとした元祖レンズのストリング図へと変形します。変形に使う法則は、既に出た次の法則です。
次の絵からスタートします。2つの具象レンズを結合した絵です。
黒丸のノードを分岐を超えて左に移動します。コピーされて2つの黒丸ノードになります。
対角射〈コピー射〉の余結合律により、ワイヤーを繋ぎ替えます。
レイアウトを変更します。
さらにレイアウトを変更します。
下の図の丸で囲った部分と四角で囲った部分に注目してください。それぞれ、元祖レンズのgetパートの結合、putパートの結合と同じです*4。
Webサーバー・コンポネントの結合と、ストレージのget/putの結合は一見違うように見えますが、実質的には同じなのです。
おわりに
具象レンズは(元祖レンズも)順行パートと逆行パートの2つの写像のペアになっています。互いに逆方向の写像を組み合わせることにより、双方向のデータ処理や双方向の情報通信のモデルとなっているわけです。
冒頭でも述べたように、元祖レンズ/具象レンズから様々な一般化がされていて、ナントカ・レンズが矢鱈にあります。一般化のために、けっこうヘビーな圏論的道具立て(グロタンディーク構成、アクテゴリー、コエンド計算、パラ構成など)が使われたりもします。
ですが、アブストラクト・ナンセンスに飛び込む前に、元祖レンズ/具象レンズとそのストリング図をいじっておいたほうがよいかと思います。