Oberon が、レコードの型宣言には存在せず、その拡張機能の 1 つにのみ存在するレコード内のフィールドのアドレス指定を許可するかどうかを調べようとしています。
PIO (" Programming in Oberon ") の 62 ページ、最初のパラグラフの最後の文で、Wirth は次のように書いています (1):
これで、プログラミングのオブジェクト指向パラダイムの簡単な紹介を終わります。Oberon をサポートするために Oberon に追加する必要のある言語機能はほとんどないことを認識しています。レコードと手続き型の既存の機能とは別に、型拡張の概念だけが必要かつ重要です。型の階層を構築し、不均一なデータ構造を構築することができます。厳密な静的型付けのルールを放棄した結果、動的型付けテストの導入が必要になりました。型ガードのその他の機能は、便利な機能の 1 つにすぎません。
PIO の 59 ページ、セクション 23.2 の前の最後の段落の最初の 3 つの文で、彼は次のように書いています (2):
p はフィールド半径を持たない Figure 型であるため、単純な指定子 p.radius は受け入れられません。型ガードを使用すると、プログラマーは、この場合 p も Circle 型であることを確認できます。この場合、フィールド半径は実際に適用されます。p は基本タイプの Figure ですが、p(Circle) はタイプ Circle です。
一方で、指定子の型宣言に含まれていないフィールドをアドレス指定できるようにするために、型ガードが絶対に必要であると #2 を解釈します。型ガードがなければ、そのようなフィールドをアドレス指定すると、コンパイル時エラーが発生するはずです。
一方、#1 で示唆されているように、タイプ ガードが単なる便宜上のものである場合は、省略することもできます。その機能は単に assert の機能であり、その結果、コンパイラは指定子の型宣言に含まれていないフィールドのアドレス指定を許可する可能性があります。
後者はタイプ セーフではないため、Wirth がそのように意図していたとしたら驚きです。
したがって、私は #1 を完全に無視して #2 を実装する傾向があります。
Wirth に電子メールを送信する前に、Oberon の実践者 (およびコンパイラの実装者) が、それぞれの Oberon コンパイラでこれがどのように解釈されるかを共有していただければ幸いです。
前もって感謝します