解决修补程序方法

是大于 0 的<gtr=“9”/>，即<gtr=“10”/>的子类型。本来不存在于 Python 的类阶层中。Erg 如何解决这个补丁的方法呢？

1.times do:
    log "hello, world"

是<gtr=“13”/>的补丁方法。由于<gtr=“14”/>是<gtr=“15”/>的实例，所以首先要沿着<gtr=“16”/>的 MRO（方法解析顺序）进行搜索。Erg 在<gtr=“17”/>的 MRO 中有<gtr=“18”/>，<gtr=“19”/>。它来自 Python（在 Python 中<gtr=“20”/>）。<gtr=“21”/>方法在这两个方法中都不存在。从这里开始，进入该子类型的探索。

整数在其上位型中显然应该具有实数和复数，甚至是整体数，但在与 Python 具有互换性的层中却不出现这一事实。但是实际上在 Erg 中，和<gtr=“23”/>是<gtr=“24”/>。至于<gtr=“25”/>，虽然是与<gtr=“26”/>没有继承关系的类，但作为类型被判断为具有互换性。究竟是怎么回事？

对于某个对象，其所属的类型有无数个。但是实际上必须考虑的是拥有方法的类型，即只有拥有名字的类型。

Erg 编译器拥有所有提供方法及其安装的补丁型散列映射。每次新定义类型时，此表都会更新。

provided_method_table = {
    ...
    "foo": [Foo],
    ...
    ".times": [Nat, Foo],
    ...
}

具有方法的类型为<gtr=“28”/>，<gtr=“29”/>。从这些中，寻找符合型的。符合判定有两种。筛型判定和记录型判定。从筛型判定开始进行。

筛子型判定

检查候选类型是否与类型<gtr=“32”/>兼容。筛型中与<gtr=“33”/>兼容的有<gtr=“34”/>，<gtr=“35”/>等。<gtr=“36”/>，<gtr=“37”/>等有限元的代数运算类型，如果声明为基本类型，则被归一化为筛子类型（即，<gtr=“38”/>，<gtr=“39”/>）。在这次的情况下，由于<gtr=“40”/>是<gtr=“41”/>，所以<gtr=“42”/>与<gtr=“43”/>是兼容的。

记录类型判定

确认是否与候选类型为 1 的类兼容。此外，当<gtr=“45”/>的补丁，并且<gtr=“46”/>具有所有的要求属性时，也具有兼容性。

因此，是合适的。但是，当<gtr=“48”/>也符合时，根据<gtr=“49”/>和<gtr=“50”/>的包含关系进行判定。也就是说，选择子类型的方法。如果两者没有包含关系，则会出现编译错误（这是一种安全措施，可防止执行与程序员意图相反的方法）。为了消除错误，必须明确指定修补程序。

o.method(x) -> P.method(o, x)

全称补丁程序方法解析

定义如下补丁。

FnType T: Type = Patch T -> T
FnType.type = T

在补丁的基础上可以进行以下代码。这又将如何解决呢？

assert (Int -> Int).type == Int

首先，中<gtr=“53”/>以以下形式登录。

provided_method_table = {
    ...
    "type": [FnType(T)],
    ...
}

检查是否符合的补丁类型。此时，<gtr=“55”/>的补丁类型为<gtr=“56”/>。这符合<gtr=“57”/>。匹配后，进行单相化置换（取<gtr=“58”/>和<gtr=“59”/>的 diff。<gtr=“60”/>）。

assert FnType(Int).type == Int

3.2 KiB Raw Blame History Unescape Escape

解决修补程序方法

筛子型判定

记录类型判定

全称补丁程序方法解析

3.2 KiB

Raw Blame History