1. Procedural ProgrammingがGUIで成立するための前提条件

手続き型プログラムが成立するには、最低限次の条件が必要になる。

1. 処理の開始点を自分で決められる
2. 次に実行される処理が決定的である
3. 関数呼び出しの文脈（call stack）が継続する

CLIやバッチ処理では、これらは暗黙に満たされている。main()から始まり、return によって必ず制御が戻る。

しかしGUIでは、1の時点でこの前提が崩壊する。

2. GUIプログラムは「自分で動いていない」

GUIアプリケーションは、自分で実行されているように見えるが、実際には OSのイベント配送機構に呼び戻されているだけである。

・マウス入力

・キー入力

・ウィンドウ操作

これらはすべてOSからの非同期通知であり、GUIフレームワークはそれを受け取って「今この関数を呼びなさい」と命令される。

重要なのはここだ。

GUIコードは「次にどの関数が呼ばれるか」を一切決められない

この時点で、処理の流れをコードで保持する手段は消える。

3. Event-driven Programmingの正体ー長寿命スタックを前提にできない実行モデル

イベント駆動の本質はこれに尽きる。

GUIプログラムは、call stack を状態保存に使えない。

なぜなら：

・各イベントハンドラは前回の処理文脈とは無関係に呼び出される

・前のイベント処理がどこまで進んでいたかをstack 上に保持できない

つまり、

・「途中まで実行して、次の入力を待つ」

・「この関数の続きから再開する」

という発想そのものが不可能になる。

結果として、状態は必ずヒープ（オブジェクト・変数）に退避される。

これがGUIにおいて「状態管理がすべて」と言われる根本理由である。

4. Event Loopがやっていること

イベントループは単なる while 文ではない。実際には次の3つを同時に満たすための装置である。

概念的には以下と等価である。

重要なのは、handler 実行中にもOSは次のイベントを生成するという事実だ。

イベントループは、それらを「溜めて」「順番に」処理することで、GUI状態の破壊を防いでいる。

5. なぜ長時間処理はGUIを即死させるのか

イベントハンドラが長時間処理を行うと、次のイベントは処理待ちキューに溜まり続ける。

この間、

・画面再描画

・入力応答

・ウィンドウ操作

は一切処理されない。

これはフレームワークの問題ではない。イベントループが「単一実行線」を守っている以上、避けられない結果である。

6. Button / Input / Window Close が根本的に非対称な理由

この3つの違いは、意味論ではなく破壊力にある。

Button Click

・明示的操作

・状態が安定している前提

Input Change

・状態が未確定

・再入（re-entrancy）が発生しやすい

Window Close

・現在の処理文脈を無視して割り込む

・未完了処理の存在を前提にしない

Window Close は例外や割り込みに近いイベントであり、通常の業務ロジックと同列に扱う設計は、メモリリーク・不整合・クラッシュを誘発する。

7. なぜイベントを理解するとGUIコードが50%以上減るのか

これは感覚論ではない。

イベント駆動を理解していないGUIコードには、必ず次が含まれる。

・次に起きる操作を予測する if

・過去状態を再現するためのフラグ

・stack依存の中途半端なローカル変数

イベント駆動を正しく理解すると：

・処理はイベント境界で必ず完結

・状態は次のイベント待ちの形に正規化

・stackに意味を持たせない

結果として削除されるのは、本来存在してはいけなかったコードである。

8. この実行モデルはWeb・Game・AI Toolでも完全に一致する

・Web：リクエスト間で stack は保持されない

・Game：フレーム境界で実行文脈が切断される

・AI Tool：推論完了通知は非決定順で届く

すべて共通しているのは、「長寿命スタックを信用できない」

GUIで詰まる人間は、分野が変わっても同じ実行モデルで必ず詰まる。

PythonのGUIがイベント駆動である理由は、設計思想ではなく、OS・CPU・call stack の寿命という物理的制約による必然である。GUIを正しく設計するとは、イベントを処理することではなく、スタックに状態を預けないプログラムを書くことである。