サルでもわかる「参照透過性」
Referential transparency for DUMMIES
これは参照透過性（Referential transparency）を解説する記事です
表題の 「サルでもわかる」 というのは、
ということだが、英語圏ではもっとストレートな表現として
Dummies「馬鹿な人」
というスラング表現で、 【バカ用】という現代社会ではかなりアウトぽい表現 が未だに人気で、自分が昔アメリカに留学しているときにも本屋でかなり目立っていて、実際このシリーズならわかりやすいんだろう、とよく手にとって読んでいたものだが、いつこのシリーズが社会からNG食らうのか定かではない参考書シリーズがある
さて「サルでもわかる」~ For Dummies の説明はこれくらいにして、その解説対象としての 参照透過性 という用語について
SNSでは、たとえば「関数型プログラミング好き」のユーザから以下のような言及がなされることがある
実はこういう感じの発言は非常に多く、特に本当に真面目に関数型プログラミングを学ぼうとする初学者にとっては大きな障害となっている
「参照透過性」というのはそんなに難しい概念なんだ！関数型プログラミングは入門するのが大変そうだなー
彼ら初学者が、そう思わされてしまう現状を、筆者はたいへん気の毒に感じている
このようなXのポストに見られる厳しい現状をもとに、この記事は、「サルでもわかる」 参照透過性 ~ For Dummies を目指したい
結果、 Dummies というのはけして真摯に学ぼうとする初心者のことを指しているのではない（多分それは他の誰かのことである）、という文脈もベストセラー書籍の人気タイトルにあることも感じ取れるはずだ
王様は裸である
Dummiesというのは裸でいることが多い
この記事は、
2023-12-1以降に順次 、Zennで公開予定
関数型プログラミングの入門本
Functional Programming From Scratch
関数型プログラミングをゼロからわかりやすく実用的に幅広い視点から解説！〜 圏論からFRPの構築まで
🔷UNIT 1🔷 OVERVIEW
からの抜粋です
他の抜粋記事としては、
があります
数学界隈には存在せず、関数型プログラミング界隈にのみ存在する特異な用語
- 数学界隈には存在せず、オブジェクト指向プログラミング界隈にのみ存在する特異な用語 というのがあり、それは工学的に発明された人工物だから、という話だった
- 数学界隈には存在せず、関数型プログラミング界隈にのみ存在する特異な用語 というのもある
- 特にこの5つの特異な用語は巷ではよく「関数型プログラミングの説明」として便利に使われている のだが、便利なのは説明しているつもりの書き手サイドの都合だけで、初学者にとってはもちろん何のことかわからないだろう、初学者ではないプログラマもわかっていないのが普通で、わからない新しい概念を、別のわからない言葉で説明できるわけがない
- この何のことかよくわからない用語は、単に、 命令型プログラミング へのアンチテーゼとしてのみ存在している 、つまり 命令型プログラミングありきの相対的な意味と価値しかない
- 関数型プログラミングは数学なのだが、現状ほとんどすべてのプログラマが、 工学的に発明された、数学ではない、関数型プログラミングでないほうのプログラミングスタイル を最初に学ぶことになっている、これがすでに前チャプターで詳しく見てきた 命令型プログラミング だ
- 一旦そこで常識が形成されてしまうので、その 学んだ常識をアンラーニングさせる必要 が生じる、その当たり前を再度強く否定する言葉が上記のリストだ
- 数学用語として存在していない理由、それは
-
数学としては当たり前すぎるので、わざわざそういう言葉が割り当てられていないから
-
数学の世界は 命令型プログラミング のことなど関知していないので、 命令型プログラミングありきの相対的な意味 という概念が生じようもないから
たとえば小学校でならう四則演算
これらはすべて
- 純粋関数 (Pure Function): 同じ入力に対して常に同じ出力を返す
- イミュータブル (Immutable): 変更不可能なデータ構造で、値が変更されることはない
- 参照透過性 (Referential Transparency): 同じ入力に対して常に同じ出力を返す関数の性質がある
- 副作用 (Side Effect): 関数が実行される際に、その関数の外部に影響を与えること、がない
四則演算を始めとする二項演算という代数構造と関数の関係性についてはすでに説明した箇所を再確認してほしい
という性質なのだが、これまで四則演算を学校で習ってドリルをやらされてきた人は、こういう性質について考えたことがあるだろうか？
間違いなく、当たり前のことで疑問に感じたことすらないはずだ
「同じ入力に対して常に同じ出力」 にならない、答えが変わることがある 、とか逆にまったく意味がわからないだろう
数学で「関数」といえば、それは単に関数のことであり、「純粋関数」もなにもない 、そんな奇妙な言葉も概念も存在しない
数学で「その外部に影響を与える」「副作用がある関数」なんていうオカルト現象は起こらない ので、そんな奇妙な言葉も概念も存在しない
特に 「参照透過性」 に至っては、もっともらしい言葉なのが好まれるのかわからないが、よく使われている
しかし実際、 数学には存在しない概念の、その他メンバーと同じことを言ってるだけなので、こんな説明能力もない用語は存在する必要がない
少なくとも、 関数型プログラミング界隈で特異に便利に使われている「参照透過性」が指し示そうとしている概念 は、小学生の子供でも「それがなんなのか？」当たり前に四則演算をやりながら理解しており、数学世界では当たり前すぎて無視されているような概念なので、何か意味があるように感じさせるような用語はむしろ理解を阻害する
そしてもっと悲惨なことには、この 関数型プログラミング界隈で特異に便利に使われている「参照透過性」が指し示そうとしている概念 は、哲学、論理学の由来なのだが、伝言ゲームのようなことで本来の伝統的な意味から捻じ曲げられてしまっており、真面目に取り合うと結局バカを見るという用語で、本当に存在自体が害悪のようなプログラミング界隈の用語になってしまっている
もちろんこのような説明能力がない用語によって関数型プログラミングが何か？理解することは無理で、単にここで繰り返しているとおり、「それは数学だ」とストレートに言えば事足りてしまう
このとおり、すべてプログラミングの世界の ローカルワードで、こんな奇妙な数学概念は存在してない
「ある式を等しい値に置き換えても値が変わらない」というのは、まさに小学校の算数で一番最初に習う数学の基本中の基本の作法なので、そう説明したほうが確実だ
まとめ
「参照透過性」 に至っては、もっともらしい言葉なのが好まれるのかわからないが、よく使われているが、こんな説明能力もない用語は存在する必要がない
以下は、「サルでもわかる」レベルをはみ出す、かもしれない、補足情報となる
「こんな説明能力もない用語は存在する必要がない」というのが過剰な言及だと感じた人むけの説明で、もう関数型プログラミング界隈ではすで存在してしまっているのだし、もう手遅れで仕方がないけど、 極めて胡散臭い破綻した用語 である、ことの確認となる
この手の用語の問題というのは複雑だったり胡散臭い事が多いので要注意である、という文脈もこめて、興味のある読者はGoogle翻訳やChatGPTを活用して読んでほしい
そもそも巷の関数型プログラミング世界で言われている「参照透過性」という言葉は 分析哲学 由来なのだが、そのオリジナルの意味から逸脱した、なんかそれっぽい名前がついてるだけの疑わしい、眉唾の用語、というのは間違いない
たとえば、この胡散臭い用語があたかも正当であるかのように説明している関数型界隈の代表格がHaskellWikiで、実際この辺はまったく参考にならないことが多い
...この用語は、Christopher Strachey によって初めてプログラミング言語の研究に導入されました
などと、もっともらしく書いてあるのだが、ならば・・・と、このStracheyの件をちゃんと調べてみると、結果、このHaskellのコードをこの下につらつらと並べて「だから素晴らしい概念なんですよ」と言わんばかりのWikiページの記述が実はトンデモだとわかってくる
What is referential transparency? Stack overflow
という２つの回答に、この不可解な「参照透過性」Referential transparency という用語の出自が詳しく解説されている
以下ごく一部を抜粋して和訳もつけているが、全文を機械翻訳も活用して読み通すと、 いかにいい加減な経緯で、伝統的な言葉の意味が歪曲されて乱用されるに至ったのか がよくわかるはず
1つ目の回答では、
The use of "in essence" suggests that Strachey is paraphrasing it in order to explain it in simple terms. Functional programmers seem to understand this paragraph in their own way. There are 9 other occurrences of "referential transparency" in the paper, but they don't seem to bother about any of the others. In fact, the whole paper of Strachey is devoted to explaining the meaning of imperative programming languages. But, today, functional programmers claim that imperative programming languages are not referentially transparent. Strachey would be turning in his grave.
「本質的に」という表現の使用は、ストラチーがそれを簡単に説明するために言い換えていることを示唆しています。関数型プログラマーは、この段落を自分たちなりに理解しているようです。論文中には「参照透明性」が他に9回出現しますが、それらについては気にしていないようです。実際、ストラチーの全論文は、命令型プログラミング言語の意味を説明することに専念しています。 しかし、今日では、関数型プログラマーは命令型プログラミング言語が参照透明でないと主張しています。ストラチーは墓の中でひっくり返っているでしょう。
最初のほうで、「この何のことかよくわからない用語は、単に、 命令型プログラミング へのアンチテーゼとしてのみ存在している 、つまり 命令型プログラミングありきの相対的な意味と価値しかない 」と説明した
そして、関数型プログラミング界隈で、 実際そのとおりの意味で適当に乱用されまくっていること 自体は紛れもない事実である
しかし、その 現状の事実ベースの説明すらこの本家由来の用語の文脈では破綻してしまう、つまりめちゃくちゃで、どうしようもない
これが、 こんな説明能力もない用語は存在する必要がない とする理由
2つ目の回答では、
This is completely at variance with what the philosophers/logicians say. They say that a context is referential or referentially transparent if an expression in that context can be replaced by another expression that refers to the same thing (a coreferential expression). Who are these philosophers/logicians? They include Frege, Russell, Whitehead, Carnap, Quine, Church and countless others. Each one of them is a towering figure. The combined intellectual power of these logicians is earth-shattering to say the least. All of them are unanimous in the position that referents/denotations exist outside the formal language and expressions within the language can only talk about them. So, all that one can do within the language is to replace one expression by another expression that refers to the same entity. The referents/denotations themselves do not exist within the language. Why do the functional programmers deviate from this well-established tradition?
これは哲学者や論理学者の言うこととは完全に異なります。彼らは、コンテキスト内の式を同じものを参照する別の式(相互参照式) で置き換えることができる場合、そのコンテキストは参照的または参照透過的であると言います。これらの哲学者/論理学者は誰ですか? それらには、フレーゲ、ラッセル、ホワイトヘッド、カルナップ、クワイン、チャーチ、その他無数のものが含まれます。それぞれがそびえ立つ人物です。これらの論理学者たちの知的な力を合わせ持つことは、控えめに言っても驚天動地です。指示対象・指示は形式言語の外側に存在し、言語内の表現はそれらについてのみ語ることができるという立場では、いずれも一致している。したがって、言語内でできることは、ある式を同じエンティティを参照する別の式で置き換えることだけです。指示対象/指示自体は言語内に存在しません。 なぜ関数型プログラマはこの確立された伝統から逸脱するのでしょうか?
The reluctance of functional programmers to call such languages "referentially transparent" merely implies that they are reluctant to admit such complex mathematical/conceptual objects as "values". On the other hand, they seem perfectly willing to call a state transformer a "value" when it is put in their own favourite syntax and dressed up with a buzz word like "monad". I have to say that they are being entirely inconsistent, even if we grant it to them that their idea of "referential transparency" has some coherence.
関数型プログラマーがそのような言語を「参照透過的」と呼ぶことをためらうのは、単に、そのような複雑な数学的/概念的オブジェクトを「値」として認めることに消極的であることを意味します。一方で、彼らは、状態トランスフォーマーを自分たちのお気に入りの構文に置き、「モナド」のような流行語で飾り付けた場合には、それを「値」と呼ぶことに全く抵抗がないように見えます。 たとえ彼らの「参照の透明性」という考え方にある程度の一貫性があると認めたとしても、彼らはまったく一貫性を欠いていると言わざるを得ません。
ここで例のHaskellWikiに戻ると
と歴史的経緯が曲がりなりにもつまみ食いはされていて、あたかも歴史的に正当で伝統を継承する概念・・・かの如く読者を錯覚させるページの立て付けになっているのだが、ちゃんとしたその筋の識者からは、
なぜ関数型プログラマはこの確立された伝統から逸脱するのでしょうか？
前に戻ると、
ストラチーは墓の中でひっくり返っているでしょう。
とこっ酷く、その伝統の観点からディスられている
彼ら＝関数型プログラマーたち 、は、 彼らの「参照透過性」「参照透明性」という言葉づかいに一貫性がない 、みたいにその筋の有識者からは一貫性すら認められていない（プログラマーなのに）ということは知っておく価値がある
もちろん、こういう局面になるとプログラム界隈の「集団的自己正当化」と言えば良いのだろうか？お決まりの流れがあって、それは
プログラミングの「参照透過」というのは意味が違う
という文句だ
しかし、少なくともHaskellWikiが顕著だが、あたかも伝統的な「参照透過性」を継承するような延長概念として、しかもStracheyの名前も借りて説明しているわけで、どこにも「プログラミングでは意味が違う」というような説明の痕跡が存在していない
事実は伝言ゲームをやっているうち意味を取り違え、まったく真逆の意味の解釈をしたり言葉を歪曲してきたにすぎないが、そういうことも説明もされてはいない
従って、 プログラミングの「参照透過」というのは意味が違う というのは単なる結果論であり、それは過失や歪曲による結果であり、正当化できるものでもなんでもない
そして、この胡散臭い言葉を珍重している人、特に、SNSで、
「参照透過性」もきちんと理解できてない
と繰り返し発言している「関数型プログラミング」をまるで自分たちだけのテリトリーだといわんばかりの「関数型プログラミング好き」の連中の理解は如何ほどのものなのだろうか？
ぜひ初学者の人たちは彼らに惑わされることなく、「裸の王様」に向けては毅然と指摘できる知見を養って欲しいと説に願う
Discussion