「予約語がない！？」PL/Iの識別子命名規則と、その深淵なる世界へようこそ
こんにちは。メインフレームの深淵を覗き込み、数十年にわたるレガシーコードの海を泳いできたシステムアーキテクトです。
JavaやCOBOLの経験がある皆さんにとって、PL/I（ピーエル・アイ）という言語は少し奇妙に見えるかもしれません。特に「識別子（変数名）のルール」は、他言語の常識で考えると「えっ、そんなのアリなの？」と驚くような仕様が隠されています。
今日は、その「PL/Iの懐の深さ」を紐解いていきましょう。怖がる必要はありません。一つずつ、紐解けば簡単ですからね。
—
1. 識別子の基本ルール：自由度の高さは「諸刃の剣」
PL/Iの識別子は、基本的には以下の文字で構成されます。
- 英字（A-Z）
- 数字（0-9）
- 国別文字（@, #, $）
ここまでは他言語と似ていますが、PL/Iには「予約語」という概念が存在しません。
これが何を意味するか？
例えば、Javaであれば `IF` や `THEN` を変数名に使うことはできませんよね。しかし、PL/Iの世界では以下のような宣言が文法上は合法として通ってしまうのです。
/ 悪夢のような変数名の例 /
DCL IF FIXED BIN(15);
DCL THEN CHAR(10);
/ 処理の中で使うとどうなるか /
IF = 10;
THEN = ‘HELLO’;
コンパイラは、これが「命令（予約語）」なのか「変数名」なのかを、文脈（コンテキスト）から判断します。これを「コンテキスト依存」と呼びます。非常に柔軟ですが、やりすぎるとコードの可読性が地獄と化します。「できるからといって、やっていいとは限らない」。これがPL/Iを扱う上での最初の教訓です。
—
2. 識別子の有効範囲（スコープ）と「暗黙の宣言」
PL/Iのもう一つの特徴は、変数のスコープ管理です。ブロック（`BEGIN` 〜 `END` や `PROCEDURE` 〜 `END`）単位で変数の寿命が決まりますが、ここで注意が必要なのが「暗黙の宣言（デフォルト宣言）」という仕様です。
もし、あなたが変数を `DCL`（DECLARE）せずにいきなりコードで使った場合、PL/Iコンパイラはどうするでしょうか？
- 現代の言語： 「エラー！変数が見つかりません」
- PL/I： 「おっ、新しい名前だな。よし、勝手にルールに基づいて変数をこさえておいてやるぞ！」
これを「デフォルト宣言」と呼びます。例えば `IBM_VALUE = 100;` と書いたとき、その名前が `I` で始まるため、コンパイラは親切心（おせっかいとも言う）から「これは `FIXED BIN` 型の変数だろう」と予測して自動定義してしまいます。
これ、大規模なバッチ改修の現場では「スペルミスした変数名が、新しい変数として勝手に生成され、バグの温床になる」という大惨事を引き起こします。
安全に開発するための鉄則
現場では必ず、プログラムの先頭に以下を記述してください。
/ 開発時の必須設定：暗黙の宣言を禁止する /
(DEFAULT(DECLARATION)) : PROCEDURE OPTIONS(MAIN);
/ これを書いておけば、宣言漏れはコンパイルエラーとして検知可能になります /
—
3. 実践コード：識別子の定義と活用
では、実際に現場でよく見る「正しく安全な」変数の定義例を見てみましょう。
/
- 構造体（STRUCTURE）を使った定義の例
- PL/Iでは複数のデータをひとまとめにするのが得意です
/
DCL 1 EMPLOYEE_REC,
3 EMP_ID CHAR(6), / 社員番号 /
3 EMP_NAME CHAR(30), / 名前 /
3 EMP_SALARY FIXED DEC(9,2); / 給与（小数点以下2桁） /
/ 変数名には $ や # を使って、意味を持たせることがあります /
DCL #TOTAL_COUNT FIXED BIN(31) INIT(0);
DCL $TAX_RATE FIXED DEC(5,4) INIT(0.1000);
TOTAL_COUNT = #TOTAL_COUNT + 1;
このように、`#` を使って「これはカウンタ変数だな」と一目で分かるように命名するのは、レガシー現場の伝統的な知恵の一つです。
—
最後に：PL/Iは怖くありません
PL/Iは、1960年代に設計された非常に野心的な言語です。当時は「何でもできる（Programming Language One）」という名前の通り、物理メモリを直接叩くような低レイヤーから、ビジネスロジックのような高レイヤーまでを一つの言語でカバーしようとしました。
だからこそ、自由度が高く、今回ご紹介したような「予約語がない」「暗黙の宣言がある」といった独特の仕様が残っています。
「ルールが緩いということは、書き手の技量が問われるということ」。
最初は戸惑うかもしれませんが、一つずつ「なぜこうなっているのか」という設計思想に触れていけば、これほど強力な武器はありません。
もし現場で不可解な挙動に出会ったら、まずは深呼吸をして、コンパイラがどのようにその識別子を「解釈」しているのか、文脈を追いかけてみてください。きっと、その向こう側に答えが見えてくるはずですよ。
それでは、また次回のレガシー探訪でお会いしましょう！
