PFIセミナー 2013/02/28 田中英行「プログラミング言語の今」

1. プログラミング言語の今
PFIセミナー 2013/02/28
田中英行<tanakh@preferred.jp>

2. 自己紹介
 田中英行 (@ tanakh, http://tanakh.jp/ )
 （株）Preferred Infrastructure 研究開発部門
 Haskell愛好家
 拙訳「すごいHaskell楽しく学ぼう！」好評発売中！

3. 本日の概要
 プログラミング言語って？
 みんな書いてるものだけど
 研究ってどんなことするの？
 プログラミング言語研究の最前線
 どういうことやってるの？
 面白さとか

4. プログラミング言語の学会

5. プログラミング言語学会四天王
（Impact Factorに基づく）
POPL PLDI
ICFP OOPSLA

6. プログラミング言語学会四天王
POPL PLDI
ICFP OOPSLA SPLASH

7. :::::::: ┌─────────────── ┐
:::::::: ｜ OOPSLAがやられたようだな… │
::::: ┌───└───────────ｖ───┬┘
::::: ｜フフフ…奴はSIGPLAN四天王の中でも最弱 … │
┌──└────────ｖ─┬────────┘
｜ たった24回でリニューアルとは│
｜ OOPの面汚しよ… │
└────ｖ────────┘
|ﾐ, ／ ｀ヽ /! ,.──､
|彡/二Oニニ|ノ /三三三!, |!
`,‘ ＼､､＿,|/-ｬ ト `=j r=ﾚ /ミ !彡
T 爪| / /￣|/´＿_,ｬ |`三三‐/ |`=､|,=’|
/人 ヽ ミ=‘／|`:::::::/ｲ＿_ ト｀ー く＿＿,-, ､ _!_ /
/ `ー─’“ |_,.イ､ | |/､ Y /| | | j / ﾐ`┴‘彡＼
POPL PLDI ICFP

8. POPL
 ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages
 今年で40周年を迎える、
プログラミング言語のトップカンファレンス
 プログラミング言語全般に関する話題
 Parallel, Concurrent
 Semantics
 Type Systems
 Formal Verifications, Proof, etc…
 近年はテーマが発散気味

9. 豊富な併設イベント

10. どんなことやってるの？
 プログラミング言語全般の研究
 「Principles」 of Programming Languages…
 特に人気のあるジャンルは、細分化されてワークショップに
 Verification Model-Checking Abstract-Interpretation
 Practical Aspects of Declarative Languages
 Partial Evaluation and Program Manipulation
 Data-Driven Functional Programming
 etc…

11. DDFP
(Data-Driven Functional Programming)
 乗るしかない、このBigDataに！
 という感じの今年出来たワークショップ
 とにかくナウい

12. tryF#
http://www.tryfsharp.org/
 来るべきBigData時代を見据えて（？）
プログラミング言語はどうあるべきなのか？
 F# 3.0では Information Rich プログラミングというものを標榜していた
 tryF# では、Webで Information Rich プログラミングを体験できる
 Webの開発環境が恐ろしい完成度

13. プログラミング言語って何ですか？
研究するものなんですか？

14. あなたにとっての
プログラミング言語とは？
 科学？
 数学？
 魔法？
 宗教？
 文学？
 哲学？

15. 科学的立場：
研究と現場の乖離
(´･_･`)実際問題意識ある

16. 研究と、実用までの隔たり
20
・GC
技 ・型推論
術
20 ・ラムダ式
・etc…

17. 魔術としてのプログラミング

18. 文芸としてのプログラミング

19. 宗教としてのプログラミング言語
http://www.bugbearr.jp/?プログラミング言語%2F宗教論争

20. 謎の喩えの数々
ユーザ
嫁
刃物

21. プログラミング言語とは何なのか？
 コンパイラはどこに入る？
アプリケーション
ミドルウェア
OS
(´･_･`)どこに入るとも言い難い…
ハードウェア

22. プログラミング言語が、
ほかの計算機科学の分野と異なる点
 プログラミング言語処理系、それ自身がプログラムである
 プログラミング言語は、本質的に自己言及を伴う分野である
 （かつ、本質的にすべてのプログラマに影響を与える）
 油断すると、あらゆる矛盾、パラドクスがやってくる
 (´･_･`)「そしてパラドクスは、哲学、オカルト、最終的には宗教まで介入させる」
 (`･д･´)「宗教て！」

23. 自己言及のパラドックス
（嘘つきのパラドックス）
 「この文は偽である」← は真か偽か？
 (´･_･`)「真だとすると、「この文は偽である」というのが偽になって矛盾する
し、偽だとすると、「この文は偽である」が真になってしまうし……」
 (`･д･´)「どっちやねん！」

24. ラッセルのパラドックス
（素朴集合論）
 自分自身をそれに含まないものの集合をA、含むものの集合をBとする
 「Aの要素全てからなる集合」は、A、Bどちらに含まれるのだろうか？
 (´･_･`)「Aに含まれるとすると、その集合は自分自身を含まないことになるけ
ど、そうすると、その集合がAに含まれるのはおかしいし、Bに含まれるとして
も、逆の理由でおかしくなるし…」
 (`･д･´)「どないやねん！」

25. ラッセルの型理論（階型理論）
 素朴集合論の問題を解決するために、構築される
 自己言及的な命題を記述できないようにすればいい
 （詳細は略）要するに、式を型で分類するという発想
 「プリンキピア・マテマティカ」にて定義
 現代のプログラミング言語における、型理論、型システムの礎

26. ゲーデルの不完全性定理
 「プリンキピア・マテマティカと関連体系における決定不能な命題についてI」
 第1不完全性定理
 自然数論を含む帰納的に記述できる公理系が、ω無矛盾であれば、証明も反証もできな
い命題が存在する。
 第2不完全性定理
 自然数論を含む帰納的に記述できる公理系が、無矛盾であれば、自身の無矛盾性を証明
できない。

27. どういうこと？
 ゲーデルの定理では、ゲーデル数というものを持ち出すことにより、巧妙に型の
間をすり抜け、不完全性を導く……
 (´･_･`)「なるほど、わからん！」
 (`･д･´)「という人には、『数学ガール ゲーデルの不完全性定理』がお勧めだ」

28. 時に数学は、
数学の世界の外で語られる
 フェルマーの最終定理が話題に
 最近だとペレルマンによるポアンカレ予想の解決
 ゲーデルの定理は、昔から根強く、最も人気のあるコンテンツの一つ
 (´･_･`)「数学以外でも、シュレディンガーの猫やら、相対性理論やら、ヴィトゲ
ンシュタインやらはよく出てくるね」
 (`･д･´)「ライトなSFがお手軽にインテリ風になるらしいぞ！」

29. 数学の世界の外で起こること
 「なんかすごい定理が証明されたらしいぞ！」
 「えー、それってどんなことなのー？」
 「詳しいことはよくわからんけど、こういうことらしいぞ」
（めいめいが、自分の言葉で自分の理解を語り始める）
 (´･_･`)「まあ、僕も数学の世界の中のことはよく知らないんで」
 (´-_-`) …「そんな時代もありました」

30. ゲーデルの不完全性定理？
 (´･_･`)「公理系が無矛盾であれば、それは自身の無矛盾性を証明できない」
 ( ˘⊖˘) 。O（待てよ……！？）
|
＼ __ ／
＿ （ｍ） ＿ﾋﾟｺｰﾝ
|ミ|
／ .｀´ ＼
∧＿∧ ／￣￣￣￣￣￣￣￣￣
（´･_･`∩＜ 数学の証明なんて全部間違いやったんや！！
（つ 丿 ＼＿＿＿＿＿＿＿＿＿
⊂＿ ノ
（＿）

31. ゲーデルの定理の濫用例
 「ゲーデルの不完全性定理は、客観的現実の存在は証明できないことを示してい
る」
 「ゲーデルの不完全定理によって、全ての情報は本質的に不完全で、自己言及的
である」
 「存在と意識を同等に考えることによって、私たちはゲーデルの不完全性定理を
進化論に応用できる」
 「ゲーデルの定理こそ汲めども尽きぬ知識濫用の泉である」（アラン・ソーカ
ル、ジャンブリクモン）
トルケル・フランセーン「ゲーデルの定理 利用と誤用の不完全性ガイド」より

32. そして一人歩きし始める
 「ゲーデルの不完全性定理は、数学的なアプローチや証明なしにも直感的に理解
しうるものである。実際、禅仏教思想の中にも明瞭にそれとわかる形で不完全性
定理の概念が出現しているからだ。」
トルケル・フランセーン「ゲーデルの定理 利用と誤用の不完全性ガイド」より

33. 濫用の背景
 定理に出てくる専門用語が、日常で使われている言葉
 「矛盾」「無矛盾」
 「完全」「不完全」
 「体系（システム）」
 インフォーマルな意味で解釈すると
 とても破天荒なことを言っている
 面白いし、いろいろなアイデアと結び付けられてしまう（けど大抵は意味を成さない）
 ゲーデルの定理の応用は、多くの人が期待するようなものではなく、
正しく数学的な定義に従ったものに限られる

34. （チューリングマシンの）停止性問題
 プログラム（チューリングマシン）が（有限時間で）停止するかどうかを
判定する問題
 停止性問題を解くプログラム（チューリングマシン）は存在しない
(チューリングマシンの停止性問題は決定不能)
 対角線論法による証明が有名で、よく例として出てくる

35. 停止性問題の濫用
http://d.hatena.ne.jp/sumii/20090310/p2
http://d.hatena.ne.jp/noopable/20090528/1243503981

36. “
語りえぬものについては、
沈黙しなければならない
ルートヴィヒ・ウィトゲンシュタイン「論理哲学論考」命題 7
”
※誤用です

37. さて、
プログラミング言語を語るにあたって
 プログラミング言語、及びそれにまつわる研究を語るにあたっての
“ここでの”前提
 プログラミング言語研究は科学である
 プログラミング言語に関する定理、証明、その他全てのものについて、
 好む好まざる
 哲学的
 宗教的
 魔術的
 あるいはその他
 の立場に基づく、あらゆる誤用、自由連想を控えなければならない
 (´･_･`)「プログラミング言語？ただのテクノロジーですよ」

38. POPLに見る、
プログラミング言語研究の今

39. プログラミング言語研究の潮流
 Verification
 Concurrency, Memory Model
 Formal Semantics
 Types
 etc…

40. Verificationが大人気
 今、プログラムの静的形式的検証がアツい！！
 どのぐらいアツいかというと、Verificationと書くだけで、採択率大幅アップ！
 さらに、ワークショップも充実

41. 併設ワークショップ

42. 併設ワークショップ
verification

43. Verification関連の研究
 “Cache and I/O efficient functional algorithms.”
 メモリヒエラルキを考慮した、アルゴリズムのI/Oコストの静的解析
 “On the linear ranking problem for integer linear-constraint loops. ”
 ある種のプログラムに対する、停止性判定
 “The power of parameterization in coinductive proof.”
 Coqにおける、coinductionを用いた証明の改善
 Microsoft Research Verified Software Milestone Award
 CompCert（証明付きコンパイラ）プロジェクトが受賞

44. なんでそんなにVerification？
 バグを取るのは難しい、という大前提
 簡単だ、と主張する人も、いるようですが…
 検証は、テストより強し
 バグの不在の証明なので
 （なにより、形式的検証は、プログラムの性質を知ろうとすることなので、難し
い）
 （難しいことは研究になる）

45. バグのない世界を想像してみる
（ ˘⊖˘）。o（待てよ、プログラムにバグがないのなら…)
 デバッグする必要がない
 テスト書く必要がない
 テストする必要がない
 デグレードの心配がないので、プログラムのリファクタリングが自由自在
 バグ修正のためのメンテが必要ない
 プログラミングのコスト大幅減！
|POPL|┗(☋｀ )┓
三 ( ◠‿◠ )☛そんなうまい話があるか
▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわああああああああ

46. 現実：バグのないプログラムを書くのは、
それなりに大変
 型ベースの証明を書く
 Coq, Agda, etc …
 ソフトウェアの基礎
 プログラミング Coq 〜 絶対にバグのないプログラムの書き方 〜
 Symbolic Execution + SAT/SMT Solver
 sbv(Haskell), vcc(C言語), …
 モデル検査
 いろいろ
 (´･_･`)「コスト的に見合わんかもだぽよ……」

47. デバッグしづらいものに向いてる
 ハードウェア
 昔からモデル検査がよく行われてきた
 （ハードウェアに対するモデル検査は決定不能じゃないケースもある）
 並行・並列プログラム
 大体のバグが、忘れた頃にやってくる
 再現が難しい
 静的に安全だと判明した部分の、同期処理を省いてパフォーマンス向上目指すなども

48. でも、証明じゃなくて
プログラムを書きたいんです！
 (´･_･`)「僕証明とか嫌いなんで……」
証明お好きですか（脳内調べ）？
嫌い どちらかというと嫌い わからない 考えたこともない

49. Curry-Howard isomorphism
 「プログラム＝証明」「型＝命題」との間の同型対応
 (`･д･´)「この事実が示すことは……」
 (´･_･`)「つまり…どういうことだってばよ？」
 (`･д･´)「プログラムを書く事は、証明を書く事と同じってことだよ」
 (´･_･`)「な、なんだってーー（棒」

50. 穴駆動開発
（youtube: hole driven haskell）

51. 2012 Verified Software Milestone
Award: ConpCert project
 検証されたコンパイラを作ろうというプロジェクト
 Coqにより（大部分を）証明されたコード
 現在、ISO-C-90と ANSI-C といくつかのGCC拡張をサポート
 2005年スタート、2012年に浮動小数点演算の完全な形式化と検証が完了

52. なぜ、コンパイラの正しさが重要なのか？
 コンパイラは、もっとも複雑なソフトウェアの一つである
 コンパイラの正しさは、すべてのソフトウェアに影響を与える
 正しいコンパイラを作るのは難しい
 最適化が行うコードの変更によって、コードの意味が変わらないか
 メモリモデルに違反する最適化を行わないかなど
 最適化フェーズの組み合わせによって、コードの意味が変わらないか

53. Coq自身の正しさは？
 (´･_･`)「あれ、Coq自身の正しさは…」
 (`･д･´)「証明されてないな」
 (´･_･`)「CoqでCoqを書けば…？」
 (`･д･´)「”証明されてないCoq”で証明されたCoqは、正しいと言えるのか？」
 (´･_･`)「あ、これゲーデルの定理でやったところだ！！（濫用）」

54. 停止性問題再び
 Formal Verificationには、プログラムの停止性が必要なことも多い
 (´･_･`)「停止性問題から、プログラムの停止性はわからないんじゃないの？」
 (`･д･´)「そんなことはないよ！」
 完全性を考えなければ何とでもなる
 停止する・停止しない・わからん！の3択を返す関数ならいくらでも書ける
 チューリング完全じゃないプログラミング言語を使う
 停止性問題は、チューリングマシンに対する定理なので、
チューリング完全じゃなければ当然当てはまるとは限らない

55. 不完全な停止性判定アルゴリズム
 特定の性質を満たすプログラムに対するもの
 integer linear-constraint loops など
 Abstract Interpretation + SMTソルバ
 ∀input. ∃time. cycles(f, input) < time なる充足可能性問題
 もちろん決定不能（だけど、解けるときは解ける）
 Idrisとかの部分的停止性判定
 再帰の引数が短調減少になってるかだけ調べる

56. チューリング完全を捨てる
 (´･_･`)「そんな言語でまともなコード書けるんですか？Brain F*ckですらチュー
リング完全なのに…」
 (`･д･´)「かけるぞ」
 Coq：チューリング完全にならないように、慎重に設計した、非常に記述力の高
い言語（語弊有り）

57. 検証にまつわる現在の状況
 証明方面
 今現在のCoqでは、証明書くのが大変すぎるので、どげんかせんといかん
 たくさんの手法が提案されてきている
 将来的には息をするように証明が書ける世界を目指している（のかな？）
 モデル検査方面
 バックエンドのSAT/SMTソルバがここ10年ほどで驚きの爆速に
 やれることが増えてきているもよう

58. メモリモデルの話
 ここ10年ですっかりCPUがマルチコアになってしまった
 今時スレッドを使わないプログラムを書いてる男の人って…
 しかし、並行・並列プログラムはとっても難しい！
 難しいので当然研究されている
 POPLでもよく扱われている

59. double-checked lockingと
Singletonパターン
 比較的最近破綻した、有名なデザインパターン
 Singletonオブジェクトを作るときに、
2回チェックすると、ロックの回数が減らせる（はずだった）

60. Javaのメモリモデルの問題
 コンパイラの最適化、あるいはCPU内のアウトオブオーダで、メモリアクセスの
順序が入れ替わってしまう
 メモリモデルとして、形式的に定義せねばならない
 JVMのメモリモデルをSequential Consistencyとして定義（POPL2005）
 その後Counter-exampleが二度にわたりPOPLで指摘される
 今年、Buffered Memory Model による形式化（POPL2013）

61. C11/C++11のメモリモデル問題
（POPL2013）
 もともとC/C++はメモリモデルの規定がなかった
 みんな、volatile asm mfence！
 C11/C+11で Relaxed Memory Consistency が導入される
 これはこれで、いろいろ厄介な問題！
 このメモリモデル上での、ライブラリの安全な抽象化方法を考える研究

62. ちなみにCompCertでは
 x86とPPCのメモリモデルに準拠したTSOを形式的に定義
 CompCert TSO
 最適化などが、これを違反しないことを証明済み

63. JavaScriptのFormal Definition
 JavaScript and Web Tools
 executable semantics for JavaScript
 executable model of event dispatch in Web browsers
 （Coqで証明済み）
 Rhino, SpiderMonkey, V8などの違いが浮き彫りに
 そもそもどれが正しいのか
 Rhinoをリファレンス動作として採用した

64. まとめ

65. まとめ
 プログラミング言語研究の最前線の紹介
 プログラミング言語研究は、本質的にHigher-orderで自己言及的
 だからこそ、変な方向に話がそれがち
 でも、だからこそ、面白い！
m(´･_･`)m「ご清聴、ありがとうございました！」