二つの概念が一つだったとき：region と arena

前回は疑いで終わった：設計空間には arena と region の両方があり、あまりにも 似すぎていた。今回は、その疑いを結論まで追う話だ —— それらは一つの概念が二つの名前を まとっていたのであり、片方だけを残すと決めた。

二つの記述、一つのアイデア

並べて書き出すと、二つは同じ機構を描いていた。

arena：バンプポインタ割り当て、個別解放なし、arena を破棄するとき一括で解放。 一つの arena 内の相互参照は自由で、それがグラフに強い。そして片付け不要な型だけが 入れる。

region：プログラム構造に紐づくメモリ領域、ブロックにスコープされ、入れ子可能、 ブロックを抜けると一括で解放。

これらを並べると「違い」は蒸発する。バンプ割り当て、個別に解放しない、スコープ脱出で 領域ごと解放、内部では自由に共有 は、Tofte–Talpin の意味での region の教科書的な 記述だ —— ML 系言語が借りてきた、よく研究された region 計算。記述された通りの arena は、 別名の下の同じ計算だった。

見かけの区別は付随的で、本質的ではなかった：

• 入れ子は region には書かれ、arena には単に触れられていなかっただけ —— 禁じられて いたのではなく、書かれていなかった。
• 「片付け不要な型だけ入れる」制約は arena には明記され、region には暗黙だった —— だが region も、まったく同じ理由で、まったく同じ規則を必要とする。
• それぞれが少し違う構文を拾っていて、それが二つの名前を二つのものに感じさせた。

そのどれも、機能が 何であるか における本当の違いではない。異なる時期に書かれたために 乖離した、一つのアイデアの二つのスケッチだった。

決定：一つの概念、名は region

そこで二つは一つの機能に畳まれ、有用な部分の和集合を保った：スコープされ入れ子可能な 領域、ポインタを進めて割り当て、ブロック終了時に一括解放、内部の相互参照は自由 —— そして、そこに何が住めるかの一つの規則（次回の主題）。書き方は素直だ：

region r {
  // r に割り当てる。ここのすべてはブロック終了時に解放される
}

残した名は arena ではなく region だ。一つには、設計が立脚する確立した理論を名指す から。もう一つには —— 命名を扱う後の回で触れるが —— 「region」が言語自身のアイデン ティティで効いてくるからだ。

なぜ早くに畳むのか

これは片付けに見えるが、メモリモデル全体で最もてこの効いた決定の一つだった。設計 ノートが率直に述べていた理由がある：他のほぼすべてのメモリ決定が、この一つに依存 する。 view 型、region 対応の標準コレクション、片付けが走る順序 —— それらはどれも 「region はどう振る舞うか？」についての議論だ。もし重なり合う二つの概念が残っていたら、 それらの議論はどれも二度、概念ごとに行い、永久に同期させ続けねばならない。偽の区別は 無料ではない。あらゆる将来の決定に課される税だ。

先に畳んだおかげで、Part II の残りは 一つの ものについて推論できた。

言語の第一原則へまっすぐ戻る線もある。Mere は、読んで確信できるプログラムを最適化する —— そして一つのアイデアに二つの名前があることは、それに真っ向から反する。読者は違いを 学び（無い）、どちらを使うか決め（どうでもいい）、両方を頭に抱えねばならない（無駄）。 それぞれがちょうど一つのことを意味する、より少ない概念 は、明示的な型・明示的な エフェクトと同じ目標を、言語自身の語彙に適用したものだ。ここでの単純さは美学ではない。 検証可能性だ。

これが開いたもの

一つの region への統一は、二つあった間はぼやけていた問いを、すぐに鋭くした：

• region には実際、何が住めるのか？ バンプ割り当てと一括解放が効くのは、本当の 片付けを要しない値だけだ。ファイルハンドルやソケットを持つ値は、ポインタをリセット するだけでは解放できない。その制約には名がある —— Trivial —— そして片付けを 本当に 要する値のための別の物語が、次回だ。
• region への 参照とは何を意味し、それが region より長生きするのをどう止めるか？ それは数回先で、独立した小さな理論になる。

一つの概念、鋭い縁。次回：Trivial、そして region があえて入れられない値を Mere が どう扱うか。