「参照透過性」という用語は裸の王様と言えない愚者のための概念
関数型プログラミングの本を書いた。
2021年末に基本フリーで誰でも読める形で関数型プログラミングの入門書をUPした。構想だけをしていたり、トライアンドエラーでゼロから書き直したりする時間全部ひっくるめると2年ほどかかった。かなりの長編ではある。
関数型プログラミングが『銀の弾丸』であるという非常識な常識2022
ここで、少なくともこのフェイズで2年間ほど、どうやって初学者に関数型プログラミングの概念を必要十分に伝達できるだろうか？ということを結構僕なりに真剣に考えてきたと思う。
そして、この2年より前から2015年頃から、まあだいたい7年ほどかけて痛感しているのは、「参照透過性」という用語は裸の王様と言えない愚か者のための概念である、ということだ。
ここで説明しよう。というか2022年になる前に説明しておきたい。
なぜならば、2021年末この著作をUPしてから、馬鹿がTwitterでネガキャンはじめて、2015年のQiitaの馬鹿げたネガキャン騒ぎについて再言及してきたからだ。
やっぱ放置しておくのはよくないよね。
すでに本ブログで書いた、これ、である。
やはり岡部某か…。
— 斜月三星堂 (@littleHaskeller) December 10, 2021
Qiita で暴れてた頃は参照透過性も理解できてなかったからなぁ…。 https://t.co/LfxGk0guYc
Qiita でみんなに否定されまくったのにメゲないそのメンタルには感心するよ。
— 斜月三星堂 (@littleHaskeller) December 10, 2021
言ってる内容はメチャクチャだけど🤣🤣🤣🤣🤣🤣
ここで、この馬鹿がいう「みんな」とは、同列の馬鹿のことであり、「参照透過性の理解」というのは、この馬鹿どもが参照透過性なんて言葉を理解なんてしていない、あるいは理解したつもりになっているが、なんのことか本当にわかってるわけもない、あるいは「王様は裸だ」と言えない愚か者である、ということを意味する。
と逐一追加しておかないと、ツイート一つするにも精神が安定しないのか、非常にアレ界隈のアレであることは見て取れる。
だいたい参照透過性界隈のおバカさんはこういう感じなのだろう。
まず、前回も論じたが、
これが納得いった説明だとかよく言われたりする。
以上の説明で、最初の３つ
-
プログラムは関数定義の集合であり、関数呼び出しによってそれらを組み合わせる。
-
関数は first class object である。
-
文という単位は無く、プログラムの実行とは式を評価することである。
はまあまあ良い。
特に、3つ目の、
-
文という単位は無く、プログラムの実行とは式を評価することである。
というのは、著作でも最初から最後まで一貫して強調していることだ。
上の説明が「駄目」なのは、
-
プログラムは関数定義の集合であり、関数呼び出しによってそれらを組み合わせる。
-
関数は first class object である。
という最初2つが、その3つ目に統合されるので、冗長な説明である、ということだ。
はっきとした定義があろうがなかろうが、論理的に冗長であって統合できるのであれば、それは統合して構造化して初学者に提示すべきなのだが、「はっきりとした定義がない」という権威（オーソライズ）されていないと見るや否や思考停止というか、巷で言われていることを適当に列挙してそれで誤魔化してしまう。
書くなら以下のように構造化して提示すべきだろう。
１．関数型コードとは式だ。←これがメインテーゼ。
２．そして二項演算、つまり二つの式をくっつけてつなげる、という「式」がほとんどすべてで、その二項演算とは実は二項の関数と同じものだ。
３．そしてその式＝値には関数も含まれる、従って、関数を値として取り回せること＝FirstClassOjectである必要がある。
こう書くべきだろう。
- プログラムは関数定義の集合であり、関数呼び出しによってそれらを組み合わせる。
とかいうのは、「関数型プログラミング」という言葉なので、とりあえず「関数」については言及しておかなければいけないだろう、という書き手の安易な発想であり、
正確には、
- プログラムは式の集合である。
からはじめるほうが正確だし、
「関数呼び出しによってそれらを組み合わせる。」
というのは、関数合成、高階関数のことをざっくり言ってるつもりなのかはしらないが、「関数呼び出し」によって、それらの組み合わせが生じるというのは概念的にはデタラメで穏当にいっても冒頭の定義としては適当すぎる。
そして問題の箇所にさしかかる。
まず、何が致命的に駄目なのか？
というと、基本的にこの書き手、解説者は、初見者にむけて概念を教えるつもりなんてない、ってことだ。
関数型言語とは
とかいう、初見であると想定される未知の概念説明のときに、別の未知の概念を利用してはいけない。
理解とはすでに理解している概念の地道な拡張であり、無理解の上に無理解の概念を重ねて理解が生まれるはずない。原理的に。
そして何より、関数型プログラミングの理解のために、本当にこの「参照透過性」なることば、概念が必要なのか？
「最も重要なのは参照透過性」というのは本当なのか？
という疑念がある。もしこれが嘘であるならば、まったく本質でない概念に依存する形で、未知の概念を構築しようとしている。土台がない、ってことだ。
結論をすでに書いたので、「参照透過性」なんてものは関数型に最も重要な概念でもなんでもないので、嘘の説明の仕方をしている。
なるほど。前回のエントリで僕はこう書いた。
１＋２＝３
とかいう小学校の頃から慣れ親しんでいる二項演算は、二項関数と等価であり、この式こそが関数型コードだ、みたいな説明こそが大事だからです。
自分が読んだ本、あるいはこういう持ち上げられている解説ページに、小学校の頃からやってる二項演算が関数型コードの式である、という単純明快な解説がなされているのをこれまで見たことがありません。
そして二項演算ってのは、数学の定義上、ここで言われる参照透過性があるわけですが、誰が、これまで二項演算やるのに、参照透過性が重要だ、みたいな教育を受けたことがあるのでしょうか？
１＋２＝３
という二項演算の式＝関数型コードのあり方を理解するためには
「参照透過性」とは完全に不要な用語です。
こういう説明を読んでいる閲覧者は例外なく自身の体験として理解していることだろうけども、これまで彼ら、我々が義務教育からはじまっておそらく大学教育を終えるまでに、あらゆる分野の数学を学習するときに「参照透過性」なんて言葉は学校で教えられたことなど一度もなかったはずだ。
なんか、数学と独立した範囲内で、なぜかプログラミングの分野だけに、特に関数型プログラミングの初紹介を受ける際に限って、この珍妙な「参照透過性」がもっとも重要だ、みたいに言われる。
だってね、
式の構成要素がすべて同じなら、式の値は常に同じになるということ。
なんてことは、数学ではアタリマエのことじゃない（笑
そして、こんな義務教育から一貫してアタリマエの作法として受け入れられてきたことに、これまで教師は一切「特別な名称」を与えることなどしなかったし、我々生徒は、それが何かのもっとも重要な概念だ、みたいに特別扱いされたステージで概念認識することもなかったはずだ。
-
これの意味するところは、式の値を計算するのに、その時点での状態というものを考慮する必要がないということである。例えば、もし
f(x)という式の評価結果が2になったとしたら、f(x)を何回呼び出しても常に2を返す。
これも結局同じことを書いてるよね。
-
手続き型言語に参照透過性がない原因は、変数の値が途中で変わることと、式の構成要素以外のもの（大域変数など）に依存した計算ができることである。
そして、こういう説明が悪い。
結局の所、著作でも書いたとおり、手続き（命令型）プログラミングでは、数学ではアタリマエであり続けた作法を捻じ曲げているわけだが、その事を
「手続き型言語に参照透過性がない原因」
つまり、アタリマエではなくしている原因、という説明に、「参照透過性」という無用に新しく登場した用語をもって、原因がどうのと説明している。
わかりますか？
XXには以下のような特性があります。
まずここに、ホニャララという概念があり、それがもっとも重要なのです！
ホニャララはこれまで我々がアタリマエのように理解して実践してきたことです。
XXでないものが、ホニャララでない原因は、アタリマエじゃなくなっているからです。
だいたいこういう論理構造の説明の仕方で、このホニャララとかいう言葉っている？
XXとその他の「比較」アタリマエに知っていることの「差異」として紹介されるのならともかく、わざわざ耳慣れない命名された特別な概念として、もっとも重要だ、みたいにしなければいけない？結構狂った世界ではある。
大枠では
１．義務教育以来、理解して実践してきた、「式の構成要素がすべて同じなら、式の値は常に同じになる」というアタリマエの数学の知識、作法
２．命令型というそれがアタリマエでなくなった作法
３．関数型というアタリマエに戻す作法
という流れがあるわけだが、この至極単純な事実を説明するために
「参照透過性」ということばをデッチ上げて、学習者惑わせているわけである。
そして、多くのプログラマはこの「参照透過性」という混乱を招いているだけの無駄で無意味なことばを「最重要」と信じてやまない。
なんでか？こういう説明でもそう書かれているし、
「みんながそういってるから」だよね。つまり
裸の王様と言えない愚者のための概念だったこと。
こういうやつのこと。
やはり岡部某か…。
— 斜月三星堂 (@littleHaskeller) December 10, 2021
Qiita で暴れてた頃は参照透過性も理解できてなかったからなぁ…。 https://t.co/LfxGk0guYc
Qiita でみんなに否定されまくったのにメゲないそのメンタルには感心するよ。
— 斜月三星堂 (@littleHaskeller) December 10, 2021
言ってる内容はメチャクチャだけど🤣🤣🤣🤣🤣🤣
ここで、この馬鹿がいう「みんな」とは、同列の馬鹿のことであり、「参照透過性の理解」というのは、この馬鹿どもが参照透過性なんて言葉を理解なんてしていない、あるいは理解したつもりになっているが、なんのことか本当にわかってるわけもない、あるいは「王様は裸だ」と言えない愚か者である、ということを意味する。
あと、
の元記事である、
では、同列の愚者がコメント欄に湧いていて、
Wikipedia の「参照透過性」の項目には
参照透過性（さんしょうとうかせい、英: Referential transparency）は、計算機言語の概念の一種で、文脈によらず式の値はその構成要素（例えば変数や関数）によってのみ定まるということを言う。具体的には変数の値は最初に定義した値と常に同じであり、関数は同じ変数を引数として与えられれば同じ値を返すということになる。
と書いてあります。
またオンライン版の『Learn You a Haskell for Great Good!』にも
if a function is called twice with the same parameters, it's guaranteed to return the same result. That's called referential transparency ...
と書いてあります。
これらの文章を読めば UCLA を卒業した岡部氏でなくても分かると思いますが、関数に関して言えば、「参照透過性（参照透明性）」とは「ある関数に同じ引数を渡せば、必ず同じ値が返ってくること」です。
ところが Data.new() は引数としては何も渡していないのに、毎回異なった値が返ってくるんですよね。これのどこが参照透明なんですか？
それと、どちらかの方（コメントの芸風があまりにも似過ぎていて私には区別がつきかねます）のコメントに
Date.now()の場合、具体的には、暗黙の了解としてユーザの現在時刻Tがnow()の引数になっています。
と書いていますが、そもそも引数とは明示的に関数に渡すものではないですか？
Date.now() がユーザーの現在時刻を元に値を返すなら、それは Date.now() がユーザーの現在時刻を「参照」しているだけではないのですか？
もしかしたら、岡部氏や qiitapost さん、chimetorch さんは私たちとは違う次元に住んでいて同じ言葉でも違う意味になるのかもしれませんね。
異次元に住んでいる人たちと交流できるなんて、Qiita ってすごいですね。
あるいは、
（編集済み）
ブログ上でOCamlでGUIアプリを作成せよと述べたにもかかわらず、岡部氏自身はFRPを用いた実用的なGUIアプリを提示していない。
JavaScriptのDateは関数型プログラミングのストリームであり、.now()関数の返り値も参照透明と主張。
あるいは、
（編集済み）
すみませんが、これまでに何度も具体的に誤りを指摘されてきた岡部氏と全く同じご主張のようですので、これまでの議論をお読みください。特に、参照透明の定義は、岡部氏と全く同じ誤解をされているようですので、英語版Wikipedia
https://en.wikipedia.org/wiki/Referential_transparency_%28computer_science%29
や、英語版Wikipediaから参照されGoogle Scholar
https://scholar.google.com/scholar?q=referential+transparency
でもトップに来る標準的な学術論文
http://www.itu.dk/people/sestoft/papers/SondergaardSestoft1990.pdf
をご覧ください。一つ目の英語版Wikipediaの現時点での記述は（ここでの議論に関連する範囲では）二つ目や三つ目のような数多くの（というか確認できる限り全ての）査読付学術論文と整合的で信頼できます。ご参考までに、例えば以下の記述があります。
today() is not transparent, as if you evaluate it and replace it by its value (say, "Jan 1, 2001"), you don't get the same result as you will if you run it tomorrow. This is because it depends on a state (the time).
（私訳：「today()は参照透明ではありません。評価して値（例えば"Jan 1, 2001"）で置き換えると、明日に実行するのと同じ結果が得られないからです。これはtoday()が状態（時間）に依存しているためです。」）
逆に（時間にせよ何にせよ）プログラム上に存在しない暗黙の引数を考えれば参照透明などと言い出したら、状態に依存したどのような関数も参照透明になってしまい「参照透明」という概念の存在意義がなくなってしまいますので、そのような定義があり得るとは思いません。
追記：「ご回答よろしくお願いします」とのことですが、これまでの議論ですでに明白な、岡部氏と全く同じ誤りを繰り返すばかりで、誠に失礼ながらいわゆる「荒らし」が目的としか思えませんので、これ以上はご回答しかねます（他の方に有用な情報が提供できそうな場合はするかもしれませんが）。2ちゃんねるへの書き込みも私ではありません。ご了承ください。
@Lambadaは、前エントリで示したとおり、当時のTwitter名もつけると、
らくだの卯之助 (@camloeba)
プロフェッショナルな関数プログラマと紹介されているが、2chの僕を標的にした誹謗中傷スレッドで活躍していた。
さて、すでに前半で概論は説明したが、さらに踏み込んでいかにこいつらが間違っているのか解説していこう。
Data.now() は引数としては何も渡していないのに、毎回異なった値が返ってくるんですよね。これのどこが参照透明なんですか？
-
JavaScriptのDateは関数型プログラミングのストリームであり、.now()関数の返り値も参照透明と主張。
（私訳：「today()は参照透明ではありません。評価して値（例えば"Jan 1, 2001"）で置き換えると、明日に実行するのと同じ結果が得られないからです。これはtoday()が状態（時間）に依存しているためです。」）
ここで、かろうじてまともなことを書いているのが
これはtoday()が状態（時間）に依存しているためです。
だ。
著作では、
（引用終わり）
に該当する。
ここで、Date.now()
というのは、時間に「明示的に依存している」のは明白です。
これはtoday()が状態（時間）に依存しているためです。
とも書かれているだろう。
【参照透過】という無意味なBuzzワードが、言ってることは結局の所、
式の構成要素がすべて同じなら、式の値は常に同じになるということ。
なんてことは、数学ではアタリマエのことじゃない（笑
ってことでしかないので、
nowだのtodayという、時間依存の関数であると明示されている場合には、数学的な矛盾など起きない。
なぜならばそれは、
常にユーザの現在時間を指し示すインデックスであるNowをもって、
Time(Now)という関数に概念的に一致するからだ。
これで命令型で起きるような不整合があれば、示せばいいだろうが、そんなことは彼らにはできないだろう。
Date.now() がユーザーの現在時刻を元に値を返すなら、それは Date.now() がユーザーの現在時刻を「参照」しているだけではないのですか？
そうだよ、だから？
その論理ならこの、わけのわからん造語である「参照透明」のスペックは満たしてるだろう？
「（私訳：「today()は参照透明ではありません。」というのは、単にその論文の主張が間違っている。
せいぜい僕の主張よりも権威は認められる、と主張するのは自由だが、学問ってそういうもんじゃないよね？Wikipediaからリンクされてる、うん、それで？（笑
だいたいこの輩は、あとから引用するけど、オリジナルから捻じ曲げられた「参照透明」という言葉の経緯はわかって書いてるのか？
こいつがいうところの「参照透明」ってのはどういう意味で使ってるんだ？こいつのオレオレ定義か？どの意味の「参照透明」？そんな定義すらろくにされていない用語はまともな論文として通ってるのか？アホらしい。
逆に（時間にせよ何にせよ）プログラム上に存在しない暗黙の引数を考えれば参照透明などと言い出したら、状態に依存したどのような関数も参照透明になってしまい「参照透明」という概念の存在意義がなくなってしまいますので、そのような定義があり得るとは思いません。
実際に
Now
とか
Today
が、それぞれ引数として
Time(Now)
Time(Today)
というように暗黙じゃなくて明示した現在時間のインデックス値として引数にしてやっても、そうじゃなくても、どっちでもどうでもいいとおもうけど、いずれにせよ、
これ、時間依存の関数だって、明示されているのと一緒だし、実際そういう意味だってコンセンサスはあるわけだよね？（苦笑
そして、こういうくだらん、無意味な議論を引き起こすことこそ、この参照透明、参照透過というくだらない造語が害悪であるという証左。
「参照透明」という概念の存在意義がなくなってしまいますので、そのような定義があり得るとは思いません。
うん、そのとおり、非常にくだらないし、こんな「概念」の存在意義なんぞないよ。定義したのがそもそもの間違いで、王様は裸だといえないこういう馬鹿連中を量産している。
（編集済み）
@Q_Jirou さん、お疲れさまです。
私はこれまでの一連の書き込みを見て、「根本的に議論が成り立たない相手」が存在するという事実に脅威を覚えています（笑）以前私が書き込んだ「参照透過性」の定義を読んだ後にまだ「Date.now() は参照透過である」との主張を曲げないんですから、毛の人は根本的なところでの言語理解力が乏しいか、私たちの言語体系とは違った世界の住人なのだと思うことにしました。
相手が人でない場合、「人の道」を説くの無意味だと思います。残念ながら…。
@totemring
あなたはこれまでのコメントの中で何度も「コンセンサス」という言葉を使ってきていますが、あなたの「Date.now() は参照透過である」という主張はどの程度のコンセンサスが得られているのですか？
もちろん、哲学や意味論や物理の世界ではなく、我々が議論している「関数型プログラミング」の世界での話ですよ。あなたがこれほど主張しているのですから、「関数型プログラミング」に関する学術論文の中に「Date.now() は参照透過である」と書かれている論文がさぞや沢山あるのでしょう。そのうち 4〜5 編でいいので題名と著者を教えてください。
「そんなのは自分たちで調べればいいだろう」などという『悪魔の証明』を提案しないでくださいね（笑）
@totemring さん、コンセンサスの話題はスルーですか？（笑）
上記確認済みのように「値」が言語外にしか存在しない、と意味論的に正しい解釈をしていれば、そんな間違った発想はでるわけがない。
私はあくまでも「関数型プログラミング」の範疇で話をしているので、言語内の値の話をしてますよ。
哲学の話や意味論の話は聞き飽きました。「関数型プログラミング」における「参照透過性」の話をしてください。私の書き込んでいる「日本語」が理解できますか？
理解できるよ。
こいつが「哲学の話や意味論の話」を聞き飽きようが、こいつの主観がどうであれ、
そもそもの「参照透明性」「参照透過性」という厳密な議論や定義がある哲学用語、意味論のはなしを、なんか意味を捻じ曲げて混乱を引き起こすだけのBuzzワードとして「関数型プログラミング」ローカルで、数学のアタリマエの作法を言い表すためだけの目的で狂った形式で輸入された事実は変わらない。
「関数型プログラミング」における「参照透過性」の話をしてください。
うん、だからやってるじゃない。
これが馬鹿げた無意味な造語としてプログラミング分野に輸入されたにすぎないって狂った状況を説明しているんだ。
おまえが納得しようがしまいが、経緯と事実と、王様は裸だって言えない愚者が量産されてる狂った現状は変わらない。
関数型言語のプログラマたちは、それら命令型言語を「参照透過」とは呼びたがらないでしょうから、そういった複雑な数学的・観念的オブジェクトを「値」であると認めることも嫌がるでしょう。それでいてそれらの状態変換器が、彼らの好むところの文法や「モナド」などというバズワードによって取り込まれるや、「値」と呼ぶことに抵抗がなくなるようです。この姿勢は一貫性に欠くではないかと言わざるを得ません。たとえ彼らの「参照透過」の考え方にある程度の統一性が認められたとしてもです。
歴史を紐解くと、なぜこのような混乱が生じたかが、かすかに見えてきます。
つまり、ボトムラインとして、この記事のコメント欄で、わいてる一連の馬鹿どもは、定義からして結構デタラメなバズワードについて曖昧な定見で、さもわかってるように「参照透明」という言葉を使いまわしていた事実は間違いない。
僕は、なんか連中の通報でアクティブなアカウントが凍結されていたので「捨て垢」でとことんこいつら馬鹿の相手をしていたのだが、連中は自分らが寄りかかっていた「定義」がグラグラであることに気づいて、単に反論のための反論で食い下がってきた。
繰り返すけど、関数型プログラミングにおける「参照透過性」というバズワードの意味なんぞ、このエントリの前半で示したとおり、
式の構成要素がすべて同じなら、式の値は常に同じになるということ。
数学ではアタリマエのことじゃない（笑
程度の意味しかない。
そして、探究心旺盛なひとが書いた記事のように、こういう人は本当に頭がいいと思うし、こいつら馬鹿どもと異なって、王様は裸だ！と言える人なのだが、オリジナルの参照透過性とは、もっと深い意味論の話であって、そんな意味論はたかだか
式の構成要素がすべて同じなら、式の値は常に同じになるということ。
数学ではアタリマエのこと
という関数型コードのスペックを示すのに、何の関係もないし、必要どころか、害悪でしかない。
「関数型プログラミング」での「参照透過性」の概念が他の分野とは違うと書かれているのに、どうして総論的な結論が出てくるんですか？
くだらない混乱まみれの用語の自分らの過剰評価、王様が裸であることを認めたくないがために、その混乱ぶりを擁護する、そして
私は「関数型プログラミング」の範囲に限定して「Date.now() が参照透過である」ということを証明してくださいといってるんですが？
くだらん、馬鹿造語をもって、そんな破綻した概念をベースに「証明」なんぞできないんだよ。
せいぜい、
Date.now()っていうのは時間依存の関数であることは誰でも知っていて、
DateTime(Now)としでもするならば、時間依存の引数があると整合的に解釈できるし、
逆に（時間にせよ何にせよ）プログラム上に存在しない暗黙の引数を考えれば参照透明などと言い出したら、状態に依存したどのような関数も参照透明になってしまい「参照透明」という概念の存在意義がなくなってしまいますので、そのような定義があり得るとは思いません。
とかほざいてるけど、
状態に依存したどのような関数も参照透明になってしまい
なんてことはなくて、
Date.now と today()
なんて時間依存だって字面に書いてる特別な時間関数なんで、
「状態に依存したどのような関数」の話なんてしてないよね？ごまかさないでね？
そして、
「参照透明」という概念の存在意義がなくなってしまいます
そのとおりだよ。
式の構成要素がすべて同じなら、式の値は常に同じになるということ。
数学ではアタリマエのこと
の意味しか、オリジナルと違って関数型の世界ではせいぜい、その程度の意味しかないんだから。
Date.now と today()
ってのは、字面で診ても、それぞれの関数定義においても、
時間に依存する関数だ。
今、今日という構成要素がこの数学の式には入ってる。定義としてね。
式の構成要素がすべて同じなら、式の値は常に同じになるということ。
今、今日というユーザの現在値という「引数」に呼応する値は常に同じだよな？
HaskellのIOモナドも、全部時間依存の関数というタイプをそろえているだけで、関数合成して、あとで、ランタイムがWorldっていう時間引数を入れるだろ？
それと何が違うの？馬鹿どもが。
以上です。
