YOYU Stackを支える設計哲学：構文ではなく設計による分離
概要
[編集]YOYU Stackの設計は、ソフトウェアアーキテクチャにおける「レイヤ分離原則」に深く根ざしている。本稿では、この原則に基づき、なぜ筆者がインラインアセンブラを一切使用せず、例外処理も標準採用しないという設計判断に至ったかを明らかにする。また、このような判断がどのようにYOYU Stackという実装に帰結するかを論じる。
はじめに
[編集]複雑なソフトウェアにおいては、「便利さ」を理由に下位レイヤの責任範囲を上位から侵害するような設計がしばしば正当化される。インラインアセンブラや例外処理はその典型である。
筆者はこのような設計に一貫して反対してきた。レイヤを貫通して制御をねじ込む構造は、短期的には便利でも、長期的には保守性と予測可能性を著しく損なう。
本稿では、その具体的な思想と設計方針を明確にし、YOYU Stackというスタック設計における実装方針としてどのように体現されているかを示す。
インラインアセンブラの排除
[編集]保守不能性とコード拡散
[編集]インラインアセンブラはCなどの高級言語に局所的な最適化や特殊命令を組み込む手段として用いられる。しかしそれにより、次のような問題が発生する：
- 言語の文脈とCPUの命令セットの文脈が混在し、読みづらい。
- クロスプラットフォームな移植性が消える。
- 変更箇所の局所性が失われ、修正のための責任範囲が不明瞭になる。
筆者はこれを明確に拒否する。必要な場合は「関数単位」「ファイル単位」「ライブラリ単位」でアセンブラを書く。こうすることで、アセンブラというレイヤを言語の外部に位置付け、責任の明確化と管理可能性を確保する。
例外処理の排除
[編集]マルチタスク構造の混入
[編集]例外処理（try-catch, throw など）は「便利な制御構造」とされるが、本質的にはマルチタスクに近い「非同期的なスタック巻き戻し制御」であり、次の問題を引き起こす：
- スタックの通常制御フローに割り込むため、制御の局所性が破壊される。
- 実装コストと精神的負荷が高い割に、利用は局所的であり、本質的なロジックに含まれない。
- エラー処理の設計方針が言語仕様に縛られ、柔軟性が失われる。
筆者はこのような「異質な制御構造」をシングルタスク前提の言語に持ち込むことに反対する。
解決策：別レイヤでの明示的モデル化
[編集]例外処理が本当に必要であるならば、それを「別言語」「別タスクモデル」で設計し、その結果だけを明示的に利用する方が合理的である。
例えば、マルチタスク処理や非同期処理を前提としたサブルーチン群を別プロセスあるいはスレッドで実行し、シングルタスクな本体とはメッセージなどを通じてやりとりする構造が理想である。
YOYU Stackへの適用
[編集]YOYU Stackの技術的な詳細については以下の論文に譲る：
本稿で主張するレイヤ分離の設計思想は、YOYU Stackのスタック領域、フレーム破棄、gsp/spの伸縮、クロージャの構造など、全体に貫かれている。
おわりに
[編集]ソフトウェアアーキテクチャにおける秩序は、「便利さ」のために破壊されてはならない。インラインアセンブラや例外処理の排除は、その秩序の維持のための意思表明であり、YOYU Stackはその思想を最小構成で実装したものである。
今後もこの思想のもとに、簡潔で保守可能な低レベル設計を追求していきたい。