『微分可能プログラミング』はどこから来たのか

はじめに（8/3追記）

この記事を一旦書いたあと、重要な追加証言が得られたため、追記修正しています。結論もやや変わっていますが、現時点のほうがより正確です。

本編：ここから

ディープラーニングが現在これだけ流行っている1つの要因は、TensorFlowやPyTorchなどのフレームワークが非常に便利だからです。ニューラルネットワークの設計、訓練、そして分類などの推論がフレームワークを使えばとても簡単に行なえます。

普通に使っている人達は、これらのフレームワークを『ツール』あるいは『ライブラリ』だとみなしていると思います。でも実際のところ、これらはプログラミング言語です。より正確に言えば、すべてのディープラーニングフレームワークはディープラーニング計算用DSL（Domain-Specific Language、ドメイン特化言語）と見なせます。このDSLは大抵、Pythonなど他の汎用言語への埋め込み型で定義されています。

これらDSLに共通して言える特徴が微分可能性です。そのDSLで書かれたプログラムは自動で微分できて、その微分の結果に依って内部のパラメータを自動更新できるのです。

あるとき、僕はネット上のどこかで"differentiable programming language"と書いたwebページを見かけました。それがいつだったか、どのサイトだったかははっきり覚えてないのですが、2017年頃だったと記憶してます。

その後、今年チューリング賞も獲ったディープラーニングの父の1人であるYann LeCunがこんな記事をFacebookに投稿しました。2018年1月7日のことです。

OK, Deep Learning has outlived its usefulness as a buzz-phrase.
Deep Learning est mort. Vive Differentiable Programming!
（雑な訳：OK、ディープラーニングはバズフレーズになって、便利なものを遺してくれた。
ディープラーニングはお亡くなりになった。微分可能プログラミング万歳！）

そして、この記事が結構バズりました。

この記事が有名になりすぎたのか、ちょいちょい「LeCunが『微分可能プログラミング』を考えついた」と書いた文章を見かけるようになり、結構戸惑いました。しかもその後、かの Gordon Plotkin（プログラム言語理論研究の大家です）が “Some Principles of Differential Programming Languages”というタイトルの基調講演を、POPL’18という、 プログラム言語理論のトップカンファレンスでしていたのを知りました。この講演が2018年1月初旬。なので、LeCunが起源という噂とは矛盾します。

それで、僕はこのフレーズのオリジナルは何なのかを調べ始めました。折しも今年の3月にPlotkin先生が来日していて、そのおかげで重要なヒントを先生からもらうことができました。

アイデアの起源

Plotkin先生がこのアイデアを最初に知ったのは2015年のChris Olahのブログ記事だそうです。ニューラルネットと、関数型言語に登場する型システムって実は似てるんじゃない？ といった趣旨の記事なんですけど、そこには"differentiable functional programming language"（微分可能関数型プログラミング言語）というフレーズが登場します。

僕自身が調べて、これ以上前に"differentiable programming"の類の言葉を見つけることはできませんでした。 せっかくなので、Chris Olahにも直接メールを出して、このフレーズは誰かを参考にしたのか聞いてみました。その返事がこちら（もちろん、彼の掲載許可は取っています）。

I'm not aware of any discussion of "differentiable programming" exactly prior to my post, although it's possible there are things I am unaware of.
I do think there were similar ideas floating around. For example, Leon Bottou has a line in this paper drawing analogies between neural nets and list manipulation in LISP.
（雑な訳：私の記事より本当に前に"differentiable programming"の議論をしたものは知りません。私が気づいてない可能性ももちろんあるけど。
似たようなアイデアはいろいろ漂ってたとは思います。Leon Bottouはこの論文で、ニューラルネットとLISPのリスト操作が似てる、と言うようなことを書いています。）

ちなみに、Olahの記事にはYann LeCunもコメントしています。なので、彼は少なくともこの記事は読んでいますね。

その後2016年に、Atılım Güneş Baydinによる"Diffferentiable Programming"と題した講演があったようです。BaydinはOlahの記事を参照しつつ、"differentiable programming"というフレーズを何回も使っています。

さらにこの中ではDavid Dalrympleのエッセイも参照していて、ここでも"differentiable programming"という言葉を使っています。やはり、ニューラルネットと関数型プログラムが似ている、という話を書いています。
彼にもぜひアイデアの起源を聞いてみたいと思ってるんですけど、Twitterのアカウントしか見つからなかった……ので、詳細を聞けるかどうかはまだわかりません。
記事を一旦公開した後、Dalrymple氏と連絡が取れました。色々話を聞くことができたんですが、この件については以下のような証言をしてくれました。

I definitely got the idea from Olah's blog. I also have strong reason to believe LeCun read my essay before popularizing the perspective, and I think it was a substantial influence. But I'd bet LeCun also read Olah's blog already so I don't want to take much credit, except for streamlining the phrase by removing the word "functional".
（雑な訳：私はこのアイデアを間違いなくOlahのブログから得ました。また、LeCunがこれを広める前に私のエッセイを読んだ、と思える強い理由があって、なのでそれなりの影響はあったと思います。でもLeCunはOlahのブログも読んでいただろうし、たくさん手柄を主張したりはしたくありません。ただし、”functional"という単語をそのフレーズから抜いたのは私の影響だと思います。）

その証言をブログで公開していいか、と聞いてみたところ、少しの逡巡があって、以下のコメントも含めてくれ、と頼まれました。

I cited Olah's blog in the manuscript I sent to EDGE.org, but the editors removed the citation with the justification that references to outside works are against the editorial policy of EDGE.org (which prioritizes self-containedness over other intellectual virtues like giving credit where credit is due). Removing the citation then made it seem like I was implicitly claiming novelty in the essay and I regret that.
（雑な訳：私は EDGE.org （注：彼のエッセイが載ったメディア）に送った原稿にはOlahのブログへの参照を入れていましたが、外部の文献を参照するのは EDGE.org の編集方針に反する（必要なクレジットを入れるなど知財面をきれいにするより、自己完結していることに重きを置く）という理由で編集者によって削除されました。削除によって私がエッセイで暗に新規性を主張したかのようになってしまい、後悔しています。）

彼が誠実であろうとすることに、僕は敬意を評します。

ちなみに、Baydinは2018年にサーベイ論文も書いていて、この中で、"differentiable progamming"の提唱者としてChris Olah, David Dalrymple, そして Yann LeCun の3人を挙げています。

と言ったあたりなので、 僕の調べた限りだと、Chris Olahがこのアイデアを思いついた一番最初で、David Dalrympleがそのアイデアから『微分可能プログラミング』（"differentiable programming"）というフレーズを生み出しました。Yann LeCun は起源ではないですが、このアイデアを大きく普及させたのは間違いなく彼の功績です。

謝辞

記事を書くにあたり、こちらの不躾な質問に快く回答下さった Gordon Plotkin先生とChris Olah、そして David Dalrymple に感謝します。

追記

英語版も書いたよ。 bonotake.github.io

追記2

「微分可能プログラミングって昔からある自動微分と何が違うん？」って質問を頂いたのですが、というか割と想定質問だったんですけども、「深層学習の文脈で同じようなものに別の名前をつけた」とか「深層学習を一般化したら昔から自動微分と言われるようなものになった」っていうのが一番近しいのかもしれないです。そんで、深層学習向けに自動微分よりも拡張されたものになっています。
恐らくですが、本文中でも紹介したBaydinらのサーベイ論文を読むのが一番わかり易いかも。

追記3

TensorFlowなどのフレームワークが実際back propagationのときにどういう「微分」をしてるか、は↓の「ゼロディー」にめっちゃくちゃ平易に解説してあるので読んでみてください。

ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

『計算機科学から見たディープラーニング』英語版をアップロードしました

前回の記事でもお伝えした、n月刊ラムダノートに寄稿した記事をGoogle翻訳使ってざっくり翻訳して英語版のブログ記事としてアップロードしました。

bonotake.github.io

ということで、僕の適当な英語を苦にしない方なら記事がタダで読めます。
日本語がいいという方はやっぱり↓を買ってください（はあと

www.lambdanote.com

記事『計算機科学から見たディープラーニング』とHagiya triple

本日（というかついさっき）刊行された雑誌『n月刊ラムダノート vol.1, No.2』に記事を寄稿しました。ということで宣伝エントリーです。

www.lambdanote.com

この中で、『計算機科学から見たディープラーニング』という記事を書かせていただきました。

この記事を書くことになったきっかけは2つありました。
まず、ラムダノート社長の@golden_luckyさんと雑談している間にこういう話題で盛り上がり、勢いで執筆を依頼された、というのが1つ。
そしてそれと同時期に、ちょうどMLSE夏合宿2019での企画を考えなきゃいけなくて、そのネタ帳代わりに書いたという側面もあります。東大の萩谷昌己先生をお招きすることは先に決まっていて、先生のご専門である理論計算機科学の観点でディープラーニングを捉え直すとどうなるか、みたいなのを、私なりに考えて記事の形式にまとめました。

で、初稿ができたタイミングで、萩谷先生と、あと共同で企画をしたPreferred Networksの丸山宏さんとで原稿を共有したところ、丸山さんが「3人で座談会をしよう」というとんでもない提案をされ、『鼎談：新しいプログラミングパラダイムとしての深層学習』として実現しました。いやぁ、お2人のお相手を務めるのが私でいいのか、とも思いつつ、精一杯やらせていただきました。

で、その鼎談の中で、萩谷先生が発表されたのがこのスライド。私の記事を元に、さらに考察を重ねておられます。

『鼎談：新しいプログラミングパラダイムとしての深層学習』 資料（萩谷 昌己） from MLSE

www.slideshare.net

私の記事のキーポイントも、この記事の中で極めて抽象的ですが説明されているので、数学的な抽象論が平気な方はこちらを見ていただければ記事読まなくても大丈夫です。
これじゃわからん、という人は記事買ってください（ニガワラ

まぁこのスライドだけだと当日の参加者以外には不親切すぎるかもしれないので、以降、先生のスライドをかいつまんで、簡単な解説を試みようかと思います。 （繰り返しですが、この説明で難しいと思う人は記事買ってください）
まず、これは一般的なホーアの三つ組（Hoare triple）の説明です。

事前条件P・プログラムc・事後条件Qで構成される三つ組に対し、(i, o) なる二つ組が出てきますが、これはテストケースです。
iが入力、oが対応するテストオラクル。iはPを満たし、(i, o)はQを満たします。

これは今までのソフトウェアだったんですが、ディープラーニング、あるいはディープラーニングを元にした新たなプログラミングの世界Software 2.0はこの枠組みを拡張します。それがこれ。

私が記事の中で書いたのがこの構図です。（なので Imai triple なんて名前がついている。恥ずかしい……）
{P}c{Q}ではなく{P}[c]{Q}となっているのがミソで、真ん中にある[c]はプログラムではなく、プログラムスキーマ（≒特定の要件を満たすプログラムの集合）です。ディープラーニングでは、ニューラルネットワークのアーキテクチャがこれに相当します。
そして更に学習器tが存在していて、tはテストの集合{(i, o)}を与えると、一番良さそうなプログラムcを自動探索して出力します。

これを更に拡張して、{P}[c]{Q}, {(i, o)}, t の3つを定めるメタ戦略mが存在するよね、というのが萩谷先生の考察。

ちゅーことで、このメタ戦略を規定するのが新たな枠組みである Hagiya triple です。

そして現状、このメタ戦略には機械学習エンジニアEの存在も含まれるのでは、という考察。

本来的には、メタ戦略はm(P, Q, {E})と3つのパラメータを持つ関数になるんですが、現状はメタ戦略m(P, Q)とは腕のいいエンジニアの集合{E}を集めることで、この腕のいいエンジニアE達が良さげなネットワークを設計するという、大変属人的でおおよそ科学とは言えないものになっているのでは？というのが萩谷先生の問いかけです。
ディープラーニングを科学にするには、いかにこの{E}を理論的な枠組みで制御可能にしていくべきかが問われます。

いかがでしょう。小難しい話を駆け足で説明したので、どこまで理解していただけたかわかりませんが。
私が書いた記事は、この Imai triple までをかなり平易に説明したつもりのものです。なので詳細はぜひ記事を読んでください（3回目）。

あと誰か、この続きを研究してみませんか？
（お前がやれ？ ごもっとも……）

情報幾何わかった気になった

注：情報幾何の内容に触れるものではなく、ただの今の僕の心境を綴っただけのエントリーです。あしからず。

タイトルは半分誇張です。本当にわかったわけではないですが、かなり理解が進みました。
きっかけは、色々ぐぐってこの解説論文に出会ったからです。

arxiv.org

元々下記の本で情報幾何は勉強しかけていたり勉強会に顔を出し始めたりしていたのですが、仕事の合間に自習する時間がなかなか取れず、モヤモヤとしていたのです。いい本だと思うんですけどね、2冊とも。

情報幾何学の基礎 (数理情報科学シリーズ)

微分幾何 (応用数学基礎講座)

GWに時間が取れたので休みのうちに勉強したいと思っていたところ、本文が実質30ページ強の程よい長さの入門が出てきたので、丁度良いと。
結局、4節の応用のセクション除いて一通り読みました。4節も読み切る時間と心の余裕が取れてなかっただけなので、このあと読もうと思います。

もちろん、この30ページがさらさらと読めるわけもなく、実際はわからないことだらけな訳ですが……ただ最近、僕が数学書を読むときわざと試していることが、幅優先で理解していくというものです。
数学書って本来、どアタマから読んで、わからない箇所が出てくれば他の文献を当たって手を動かして考えて……とやるのが王道だと思うんですが、これ、無限に時間のある学生ならOKなんですけど、それなりに仕事抱えてる社会人がやるとまず最初の導入の章読み終わるだけで余裕で1ヶ月以上かかったりするんですよ。本論にたどり着く前に半年以上かかったり。

なので最近は、敢えて

• 一番面白そうなところから読む
• わからないことがあってもとりあえず置いといて読む

というのを心がけています。深堀りするよりまず全体のイメージをつかむことから始めて、わからないことは後で泥縄式に調べていくという方法。
画像の描画を1ドットずつ精緻に描くのではなく、モザイクだらけでもいいから全体をまず描いて、そのあとモザイク内の各タイルを詳細化していく感じ。
英文の長文読解するときに、わからない単語が出てくるごとに辞書引くのは禁忌で、わからないならわからないなりに読み流していくというのがセオリーですが、それと同じです。

ということで、他に記事を書いたりもしつつ（この詳細はいずれ）、4日くらいかけて冒頭の解説論文をだいたい読み終わりました。
情報幾何がどういう構成でどういうことをやろうとしているのか、かなり雰囲気がつかめました。統計多様体とか情報多様体とかがどういうものかもなんとなくわかったし。
というか、解説論文が非常によくまとまっていたのでかなりわかりやすかったです。

ああそうだ、上の解説論文読む前にこの動画見たんだった。

【のんびり解説】統計多様体の超入門！【情報幾何】 #VRアカデミア #005

この動画もすごく分かりやすかったので、しょっぱなのしょっぱなに観るのオススメ。
（ただし、ここで解説されてる多様体は統計多様体という名称のものそのものではない気がします。）

そんで、先の解説論文の further reading なところに以下の本がオススメされてて、Amazonのなか見検索でPrefaceとか目次とか読む限り確かに次に読む本として良さそうだったんで、さっくりポチってしまいました。

Geometric Modeling in Probability and Statistics (English Edition)

これも次にどれだけ読む時間割けるかわからないんですが、ぜひ暇を見つけて読みたいなと思っています。

2019年GWにやったこと

今年のGWは10連休だっただけに留まらず、珍しく何かに追い立てられたり体調崩していなかったり*1したので、大変充実した休みを過ごせました。
ということで、GWにやったことをここに記す。

【おしながき】

幕張メッセに行った

2日ほど。何しに行ったかはお察し。

リビングに散らかり倒していた私物を片付けた

一方で自分が作業用にしている部屋は散らかりっぱなしである。

椅子を買った

自宅で仕事するときに使ってる椅子が古い木の椅子で固く、ずっと座ってると腰とかお尻とか痛くなってぐったりするので、一念発起してまともなオフィスチェアを買いました。家具屋さんに2日通いました。
在庫の関係で配送は再来週。

記事を書いた

某雑誌向けに書きました。論文ではなく一般の読み物です。
ディープラーニングに対するエッセイというか考察というかポジショントークというか、そんなもの。詳細が決まったら明らかにします。

情報幾何をわかった気になった

以下を参照。 bonotake.hatenablog.com

微分可能プログラミングの由来を調べた

Differentiable programming, 別名可微分プログラミング。Yann LeCunが発祥だと思っている人が多いのだけども、そうではありません。
これも後日別エントリーにまとめたい。

ガンダムOOを1〜13話一気に観た

でも途中気を失っていたので後で一部見直す。

*1:直前まで不眠症を拗らせていたのですが、お薬で軽快しました。

『「コルーチン」とは何だったのか？』の裏話的な何か、とPythonコルーチン

いきなりですが、n月刊ラムダノートが創刊されました。めでたい。

www.lambdanote.com

で、この中にある @mametter さん執筆の記事『「コルーチン」とは何だったのか？』に僕はがっつり関わっていました。 後述しますが、僕と彼とのオンラインでのやり取りの中で記事が書き始められ、方針が決まっていった感じです。
なので、出版を記念してそのへんの経緯を振り返り、また僕なりの感想をまとめようかと思います。

……と思ったんですが、改めてやりとりのログを見返してたんですがアホほど膨大な量になっていて、とても全部振り返るのは無理だと悟りました。 なのでざっくりと。
当該の記事と一緒に読まれることを想定していますので、その記事で語られていることの説明はある程度省いています。 数時間前に @mametter さんが草稿を公開↓したので、そちらを読んでくれても構いません（できれば買ってほしいけど）。

mametter.hatenablog.com

目次：

経緯

きっかけ

去る2018年11月17日、仕事でPythonコードを書いていた僕が、ついasyncioパッケージ周りでコードを上手く書けないモヤモヤを夜になんとなく愚痴りました。
その中に、async/await で記述されたものを「コルーチン」*1 と呼んでいるらしい、なんかおかしい、という話をちょろっと入れたのです。

翌日の11月18日、僕の愚痴からアヤシイ匂いを敏感に感じ取った @mametter さんが思いをTwitterでぶっぱして、無事炎j……バズります。
外がいい感じで燃え盛る中、僕や @mametter さんがPythonコルーチンに感じ取った違和感はいったい何なのかを探る長い旅がスタートします。

コルーチンとは何かを探る旅

外がいい感じに炎……盛り上がっているさなか、最初に僕らの間で始まったのは、コルーチンが一番最初に活字にて著されたConwayの1968年の論文の読み会でした。
そこから23日までの5日間、とにかく色んな物を調べまくりました。思いつく限り列挙すると、

• Conwayの論文
• 非対称コルーチン（セミコルーチン）に関するDahlらの1972年の文献
• de Moura and Ierusalimschy, "Revisiting Coroutines", 2004
  • コルーチンについて非常によくまとまっているサーベイ論文でオススメ。2000年代までのコルーチンがどういうものだったか、きちんと知りたければこの論文を読むのが良いと思います。
• ジェネレータを最初に提案した？ CLU Icon なる言語の Technical Report
• PythonのPEP2つ（PEP342、PEP492）、その他Kotlin、JavaScript、C#、C++ のコルーチン関連のRFP
• 各言語でのコルーチンの用法を解説しているブログ（英語、日本語）や Slideshare/SpeakerDeck たくさん

その他もろもろ。

そいつらを読みながら、コルーチンの定義とその変遷の様子に関してああでもないこうでもないと2人で延々議論していました。 同時に、Pythonコルーチンを使って対称コルーチンを再現してみたりもしていました。（この結果は省略。そのうち紹介するかも。）
そんな感じで、自分たちがなんとなく「これがコルーチンだ」と思っていたものを、適宜事実と照らし合わせて修正、更新、あるいは補強していく作業でした。 70年代以前の論文を短い期間にたくさん読んだのも初めてで、自分たちがしていることをある時期から2人の間で「考古学」と呼ぶようになるのですが、実際、考古学というのはこういう学問なんだろうなと思った次第。

執筆が始まる

19日に入って、裏側で延々と議論していた内容を反映して、 @mametter さんが今回の記事の草稿に当たるものを書き始めます。   当初は自分のブログに書くためのもので、もっと簡素だったし、ツイートだと書ききれない @mametter さんのポジショントークというか意思表明というかそういうノリのもので、なので @mametter さんの主張が色濃く残っていました。

23日頃を境に一旦その執筆の手は止まり、2人の間で多少話題になったり、PPL*2でなにかの形で発表しようか？ などという検討をしたりはしていたものの、特段の進捗はなくそのまましばらく記事は放置されます。

 そして出版へ

年が明けて2019年の1月下旬、@mametter さんが書き溜めてあった草稿をラムダノート社長の @golden_lucky さんに見せたところ好評を得たようで、@golden_lucky さんが以前から構想していた雑誌に載せる方向で話が進んだようです（このへんは僕は直接会話に立ち入ってないのでわからない）。そこで記事の執筆も再開されます。

で、再開早々僕が主張したことは、記事の中で「何がコルーチンか／コルーチンでないか」という断定を避けた方がいい、ということでした。
上述の通り元々は @mametter さんのポジショントークだったので当然そのへんは @mametter さんなりの意見が含まれていたのですが、そこを結論として持ってくるより、むしろ僕らが調べた事実に基づいて「コルーチンの定義が揺らいでいる／変遷している」ということだけを述べ、それ以上の判断は読者に委ねたほうがいいと考えました。   結果として記事もそういう方向に軌道修正されたし、実際そうすることでいろんな立場の人がニュートラルに読める内容になり、記事の価値は上がったのではないかと個人的には思っています。

所感

ここからは、完全に僕個人の雑感です。

今回色々見てまず感じたことは、最近の言語は並列・並行にまつわる概念がごっちゃになっているということですかね。 ファイバー、コルーチン、軽量スレッド、future / promise あたりがごちゃ混ぜになってできているように感じます。 実際のところ、このへんを全部区別できる人がどれだけいるんでしょう？

1980年時のコルーチンの定義 と Pythonコルーチン

ということで、記事では最終的に「これがコルーチンだ」という断定は避ける形になりました。  ただ、 記事には載せられていないのですが、実は Marlinが「コルーチンが満たすべき基礎的性質（fundamental characteristics）」というものを書いています （Marlin’80）。 それがこれ。

• the values of data local to a coroutine persist between successive occasions on which enter it (that is, between successive calls)
  （コルーチン内にローカルに存在する値は連続する “call” の間で保持される）

• the execution of a coroutine is suspended as control leaves it, only to carry on where it left off when control re-enters the coroutine at some later stage.
  （コルーチンの実行は制御が離れたら停止し、その後のどこかでコルーチンに再入したときに制御の離れた箇所から再開する）

カッコ内は僕が今適当に訳しました。明らかな誤訳でなければ微妙なところは見逃して。  

これが記事に使われなかったのは、この定義もまた微妙な問題を孕んでいたからです。   どこらへんの解釈かというと “call” です。純粋に考えればコルーチン間の呼び出し／被呼び出しのことでしょう。 つまり、コルーチン間の非同期な呼び出しがあることが前提なんです。

ところが、ここにPythonコルーチンを持ってくると、解釈がとてもややこしくなります。
Pythonコルーチンって、他のコルーチンへの呼び出しで非同期的な中断するわけじゃないんですよね。 呼び出しで非同期的な中断をするのは、呼び出し先のコルーチンか、そいつが呼び出すさらに先のコルーチンか、その先か……がsleepするときだけなんですよ。
呼び出し＝中断の合図ではないんです。

でも、Marlinがこれを著したときにあったのは、対称コルーチンと非対称コルーチンだけでした。 この2つは他のコルーチンを呼び出すことで非同期的な中断をする仕組みで、呼び出し＝中断 なんです。 だからPythonコルーチンはこのMarlinの定義がそのまま当てはまるわけじゃないです。

てか、Pythonコルーチンってぶっちゃけコルーチンというより、仕組みとしてはスレッドに近いんですよね。 sleepで寝て、寝てる間は一緒に動いてる他のスレッドのどれかに制御が移る。sleepが解ければスケジューラによってそのうち制御をもらって処理を再開する。
これ、スレッドなんですよ。
これにfutureの仕組みを足したものがPythonコルーチンの正体だな、と。

ではPythonコルーチンはコルーチンではないのか

ただ、ある想定を置くことで、旧来のコルーチンを使ったモデルと考えられなくもないんです。 それは、スケジューラ（Pythonコルーチンでいうイベントループ）を特別なコルーチンと考えることです。
なのでPythonコルーチンのコンテクストスイッチ（敢えてスレッド用語を使う）は、イベントループがコルーチンを呼び出すことでそのコルーチンが処理を再開する。
sleepすることでイベントループに処理を戻す。
イベントループがresumeして、コルーチンがsleepのタイミングでyieldする非対称コルーチンってことです。

これは、Dahl et al. が大昔に書いている手法で、また、Crystalのファイバーがこういうモデルを採用してたはず。
（僕が他の言語も調べた中で、Pythonコルーチンに一番似てるなと思ったのはCrystalのファイバーでした。）

このモデルを前提に、イベントループ／スケジューラによるコンテクストスイッチを先のMarlinの定義で言う”call”とみなしていいか、という点で 僕と @mametter さんで解釈が分かれて、最終的にこの定義は使えないという話になったのです。

結局何がいいたいのか

過去の論文や他の言語の仕様も調べまくって色々考えましたが、結局Pythonコルーチンって、個人的にはあまりコルーチンとは呼びたくないんですね、やっぱり。軽量スレッドと呼びたい何かです。
それが悪いというわけではないんですが、ただコルーチンとしてみるとかなり貧弱な機能しかないので、不便です。 中断する際に他のコルーチンを呼び出して、そいつに値を渡すとかできないですからね。
さっきCrystalのファイバーが似てると書きましたが、Crystalは他のファイバーとの非同期な通信機構があります。 Pythonコルーチンにはない。コルーチン間の非同期通信はfutureでやるんです。

Pythonコルーチンは一般的なコルーチンと思うとツラくて、むしろfutureを使った非同期モデルを指向してコードを書くべきなんでしょう。 積極的にfutureオブジェクトを使いまわしていくのがいいのかな、というのが今ん所のPythonコルーチンに対する僕の所感です。

*1:実際にはそれまでジェネレータベースのコルーチンはPythonに存在していましたが、それと表面上は別のものとして native coroutine という名称で導入されました

*2:https://jssst-ppl.org/workshop/2019/

兵庫県警ブラクラ摘発の何が恐怖なのか

兵庫県警によるブラクラ摘発が話題になってもう3週間ほどになるんでしょうか。

最初は中学生がこの件で「補導」（触法少年として刑法犯扱い）された事が話題になりましたけども、その後、僕は同時に摘発された男性に関する以下の記事が出て「これは本当にマズイ」と感じるようになりました。
そして、この件で僕が感じているこのザワザワした感情が 恐怖 なんだ、という認識に至りました。

nlab.itmedia.co.jp

以下、僕がこの件で何を恐怖と感じているかを書きます。
書いてあることは他でも言われていることの何番煎じかわからないものですが、あくまで僕自身の所信表明ということで。

目次：

1. ブラクラをウィルスと同列のものとして扱っている

上に挙げた記事を読む限り、兵庫県警はウィルスとブラクラの区別がつかないのではなく、むしろ区別して扱い、しかしブラクラも不正指令電磁的記録に関する罪に該当すると判断した、ということのようです。

ネットを利用する多くの人は理解していることですが、ブラクラが猛威を振るったのは2000年代前半まで。以降はブラウザが対策してほとんど何の被害も及ぼさなくなりました。ここ10年ほど、僕はブラクラの類に出くわしたことは1度もないです。
今は子どものいたずらレベルのジョークプログラムしか基本できないし、実際に今回対象になったのも子どものいたずらレベルのチャチなもの。これのリンクを貼るだけの行為を3年以下の懲役又は50万円以下の罰金に相当する犯罪として摘発する、と警察が判断したのがまず恐ろしいのです。
実際、兵庫県警は取材に「いたずらだったことは重々承知しているが、現行法では懲役、もしくは罰金刑になる犯罪」と回答したようですがそんなわけあるか。
兵庫県警は勘違いしているみたいですが、この法律は元々実害の大きいコンピュータウィルスを対象に作成されたものです。 量刑も当然そこに合わせての設定です。
厳密にはウィルスではないが同様に害の大きいマルウェアも対象にできる、ようにはしていますが、誰もジョークプログラムをウィルスと同列に扱う必要があるなんて思っていません。警察以外は。

2. ループの本質を警察が理解していない

上記の記事から、摘発されたAさんの回想による刑事とのやり取りが掲載されていますが、

Aさん：あの……僕の貼り付けたURLがそのブラクラで、そのURLをクリックした誰かのPCが壊れたんですか？

女性刑事：いや、今回のはOKボタンをクリックするとポップアップがずっと消えずに永遠と表示され続けるループスクリプトなんだけどね。

Aさん：……ポップアップがどんな物なのかは想像付くんですけど、ループスクリプトって何なんですか？

女性刑事：まぁ簡単に言えば同じ動作を繰り返すプログラムだってことだけ理解しておいて。OKボタンを押す度にそのポップアップを何度も何度も表示させるのが今回のループスクリプトなんだよね。

「ブラクラ」の一種として「ループスクリプト」があり、その「ループスクリプト」とは「同じ動作を繰り返すプログラム」だと定義しています。

この記事で、プログラマやITエンジニアが一番恐怖を感じたのはここではなかったでしょうか。僕は心底ゾッとしました。 同じ動作を繰り返すプログラムをウィルスと同等とみなして刑法の罪に問うということですから。

いや、当初からみんなこれを問題にしていたのであって、はむかずさんの「みんなで逮捕されようプロジェクト」もここの無茶苦茶っぷりを揶揄したものなんですけども、ここが兵庫県警を含む、コンピュータに疎い多くの人達に伝わってないのではないでしょうか。
恐らく警察は問題を理解してないので、このプロジェクトもただの警察への挑発としてしか受け取れていないのでは、という気がします。取材でも「自分の子どもにもそんなことが言えるのか」なんて相当頓珍漢な回答をしていますし。

プログラミングを知らない人に端的に説明すると、兵庫県警の言う「ループスクリプト」は、誰でもプログラミングをすれば絶対に書いてしまうものなんです。 それをウィルスと同様に摘発するということは、プログラミングするすべての人が摘発の対象になるということです。

以下、もう少し詳しく説明します。完全にプログラミングを知らない人向けです。

ループはプログラムに欠かせないもの

僕は情報工学科に進学した大学1年の最初に、プログラムの基本構成要素は順次、分岐、繰り返しの3つだと教わりました。今だと同じことは高校の情報の授業なんかでも教えてるかもしれません（カリキュラム知らないのでわかりませんが）。 順次は、並べた命令を順番に実行すること。分岐は、条件判断をして、判断に応じて処理を変更すること。そして繰り返しが、同じ動作を繰り返すことです。
つまりループ（繰り返し）はプログラムの中の本質的な構成要素であり、ループなしではコンピュータの機能をほとんど活かせないことになります。

どれだけループが本質的なものか。今は自動運転の開発が盛んですが、例えばアクセルの自動プログラムを作るとなったら、たいていこんな感じになるんじゃないでしょうか。

運転している間ずっと
    もし加速する必要があったら
        アクセルを強める
    もし減速する必要があったら
        アクセルを弱める
    それ以外
        アクセルはそのまま
という処理を繰り返す

つまり「アクセルを調節する」を運転中ずっと繰り返す、と書くわけです。
人間でも、運転中ずっとアクセルを調節するという行為を繰り返しているのでは。コンピュータのプログラムだって同じで、これを書けないとまともなプログラムになりません。

止まらないループは簡単にできあがる

あともう1つ、プログラミングに詳しくない人がピンとこないのでは、と思うのが、ループが止まるか止まらないかは簡単には判断できないことです。
難しい話をするなら、どんなループに対しても止まるかどうかを判断できる、という一般的な方法はないことが理論的に証明されています（チューリング機械の停止性問題の決定不能性）。 ただ、そんな小難しい話を知らなくても、プログラミングをそれなりにやったことがあればうっかり無限ループするプログラムを書いてしまって困ったという体験をした人は多いのではないでしょうか。
僕自身、もう情報科学の専門教育を受けてから20年以上経ちますが、つい先日も作成中のプログラムが止まらなくなってキーも受け付けなくなって、コンピュータを強制終了したばっかりです。 ループが意に反して止まらないのはいつでも起こり得ることなんです。

まとめると

以上の2つを踏まえて今の状況を例えるなら、しょっぱい料理を他人に出したら傷害罪として摘発されるようになった、という事ではないでしょうか。
塩や醤油は料理に欠かせない調味料で、一生無縁な料理人は恐らく存在しないでしょう。しかし、塩のさじ加減を間違えたら摘発するぞ、と警察が日本国民に宣言したのです。 こんな状況下に置かれれば、世の料理人はみな震え上がるのではないでしょうか。
しかし現に今、そういう状況下にITエンジニアが置かれているのです。めちゃめちゃ怖いし、文句の一つも言いたくなるのが分かってもらえるでしょうか。

なお、法務省の解説 によれば、バグはこの罪に問われないことになっています。 しかし意図的に作ったものや、バグを突いて悪用した場合はこの限りでないそうで。上の議論も併せて考えれば、意図的かどうかの境目はとても曖昧です。
さらに言えば、以下の点で法務省の解説レベルだと警察は簡単に無視するようで、何の気休めにもならないのです。

3. 故意犯の要件を満たしていないのでは

この点、僕は法律に関しては素人なので間違っていたらスイマセン。

最初に挙げた記事の中で、Aさんは別のジョークサイト（怖い画像が出てきてビックリさせるもの）へのリンクを貼ったつもりが、間違って問題のループスクリプトへのリンクを貼ったと述べています。 つまり、Aさんがループスクリプトを貼ったのは間違い（過失）であって、この時点でAさんは故意犯ではなくなっているように思います。
この罪は本来故意犯でないと適用できないもののはずです。 先に挙げた法務省の解説でも、「その時点において，それが不正指令電磁的記録であることを認識していなければ，同供用罪は成立しない。」としています。

にもかかわらず、兵庫県警の刑事は本人に罪を認めさせようと話を進め、最後には

チーフ男性刑事：（間違って貼ったリンク先が）PC内部のデータが破損やデリートされたり、個人情報を抜き出す悪質なウイルスだった場合のこと、考えてみろよ。

（カッコ内は筆者）

と、まったく架空の話で、しかも仮にそれが成立してもこの罪は適用できない例を出してAさんに罪を認めさせています。メチャクチャじゃないです？

まとめ：僕らはずっと声を挙げ続けないといけないのではないか

僕は基本小市民で、日常生活では割と警察に対して協力的です。好感こそあれど悪感情なんて普段は持っていません。
でもこれはダメだ。敢えていいますが兵庫県警の対応は様々なレベルで間違いを犯しているし、彼らがやったことは日本国民に対する脅威であって、認められません。
コンピュータに関わることを生業にしている僕にとっては生存権の侵害だとすら感じます。

反社会的な行為に出るつもりは更々ありませんが、彼らの暴走を止めるためには、脅威を感じた僕らはずっと声を挙げ続けないといけないのではないでしょうか。

[追記] 昨日から日本ハッカー協会が、摘発されたうち2人の弁護士費用を工面すべく募金活動を始めました。

www.hacker.or.jp

僕も募金しましたが、もし僕と同じくこの事件を脅威に感じている人は、ぜひ募金して下さい。
協会のページにも書かれているのですが、

今回のアラートループの事案がこのまま正式裁判で争われることなく略式命令が確定してしまうと、過去の有罪事例として「実績」となってしまい、他の地方警察や検察の判断にも影響し、次々と際限なく不正指令電磁的記録の対象が拡大されていってしまう事態になりかねません。

ということで、他人事ではありません。この事件で摘発された人達の罪を確定させれば、次に苦しむのは僕らです。