Oberon:如何解决 Wirth 的 PIO re type guard 中的矛盾

Question

我试图弄清楚 Oberon 是否允许对记录中不存在于所述记录的类型声明中的字段进行寻址，但仅在其扩展之一中进行寻址，并且在没有类型保护的情况下这样做。

在 PIO ("Programming in Oberon ") 第 62 页第一段的最后一句中，Wirth 写道 (1):

This concludes our brief introduction to the object-oriented paradigm of programming. We realize that almost no language features had to be added to Oberon to support it. Apart from the already present facilities of records and of procedural types, only the notion of type extension is both necessary and crucial. It allows to construct hierarchies of types and to build inhomogeneous data structures. As a consequence of abandoning the rule of strictly static typing, the introduction of dynamic type tests became necessary. The further facility of the type guard is merely one of convenience.

在 PIO 第 59 页，第 23.2 节之前最后一段的前三句他写道(2):

The simple designator p.radius would not be acceptable, because p is of type Figure, which does not feature a field radius. With the type guard, the programmer can ascertain that in this case p is also of type Circle, in which case the field radius is indeed applicable. Whereas p is of base type Figure, p(Circle) is of type Circle.

一方面，我将#2 解释为类型保护是 绝对必要的 以便能够处理不在指示符类型声明中的字段。如果不是类型保护，处理这样的字段应该会导致编译时错误。

另一方面，如果类型保护是 仅仅是 #1 建议的方便 ，那么它也可以被省略。它的功能只是一个断言，因此编译器可以允许对不在指示符类型声明中的字段进行寻址。

由于后者不是类型安全的，如果 Wirth 打算这样做，我会感到惊讶。

因此，我倾向于完全无视 #1 并实现 #2。

在我用电子邮件打扰 Wirth 之前，如果 Oberon 从业者(和编译器实现者)可以分享在他们各自的 Oberon 编译器中如何解释这一点，我将不胜感激。

提前致谢

Answer 1

我给 Wirth 教授发了电子邮件，要求澄清。

事实证明，在早期的 Oberon 语言报告中，“仅仅是为了方便”的声明确实具有误导性，因为在这些版本的 Oberon 中，类型保护语法对于解决基本类型中不存在的扩展字段是必要的。没有其他方法可以做到这一点。

然而，正如 Wirth 指出的那样，在他对 Oberon 的最新修订中，CASE 语句的语义已被扩展，以执行类型测试和对扩展中不存在于其基类型中的字段进行寻址。

CASE msg OF
  DrawMsg : msg.draw(self)
| MoveMsg : msg.move(self, msg.dx, msg.dy)
...

在这种情况下，IS 类型测试和类型保护语法都不是绝对必要的。因此，在当前的 Oberon 版本中，它们确实只是为了方便。

可以在以下位置找到最新 Oberon 版本的语言报告:

https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.Report.pdf

CASE 语句在 9.5 节中描述。