焉知非鱼 ❚
Wait the light to fall

Roles or When One Is Many

— 焉知非鱼

Roles or When One Is Many

让 Raku 与 Perl 相当不同的一点是，Raku 避免了魔法。有几个地方人们可以说，“它神奇地发生了”。但仔细看一下，通常会发现行为背后有相当好解释的机制。这就像看魔术师的把戏：我们总是知道有解释，而且它们肯定是符合逻辑的。

因此，我有个小把戏给你。看一下代码，告诉我：你在这里看到了多少个角色？

role R[::T] { has T $.a; }
class C does R[Int] { }

直观的答案当然是 1，这也是事实。但这里的部分技巧是术语的替换：在使用"角色"一词的地方，更准确的术语应该是"角色类型对象"。现在，试着猜出正确答案。而且，要确定的是，它不止一个。

Raku 魔术是如何不神奇的 #

Raku 的最大优点之一，随着时间的推移，我越来越学会重视，就是它做任何事情都要保持逻辑性。有时这并不意味着要有直觉。有些行为一开始甚至可能使初学者感到困惑。但是，在解释时，逻辑通常是相当有说服力的。Raku 提供的一套广泛的内省工具，通常对理解它有很大帮助。在这篇文章中，我将尝试以"魔术师"的方式演示如何使用其中的一些工具来将一只兔子变成许多只。

我还将在很大程度上依赖于 Rakudo 对 Raku 的实现，它是基于 NQP 的，这使得在某些情况下相当容易看到 Raku 语法的幕后。顺便说一下，这也是 Raku 中的魔法量处于可忽略不计的水平的另一个原因。你们当中有多少人，我的读者，曾经研究过 Perl 或任何你最喜欢的语言的来源？如果我为自己回答，那么就是一个词：从未。尽管 C 语言是我多年来的首选语言。但现在我会坚持要求你在你的主目录下的某个地方做 git clone https://github.com/rakudo/rakudo.git，所有其他项目都放在那里。然后，只要你遇到问题，答案很可能就在 Rakudo 项目的 src/Perl6/Metamodel 目录下的一个文件里。

四位一体 #

我不得不谷歌一下这个词。从第一部《黑客帝国》电影开始，“三位一体"对我来说就很熟悉了，但对这一行中的其他词却不熟悉。是的，这个词就是这个棘手问题的答案。Raku 角色是四位一体。这篇文章将一步一步地告诉你为什么。

在这一点上，我想提醒的是，反省和乐库元模型的一般知识将是非常有益的。一些信息可以在本周期的前几篇文章中找到，一些可以在Raku文档中找到。

第1步: 多重性 #

让我们从最简单的自省开始。

⇒ raku -e 'role R[::T] { }; say R.WHAT'
(R)

不要和 ‘⇒’ 字符混淆，这只是我最喜欢的命令行提示。

注意，我们只用方括号来声明角色，而不是对它调用方法。还要注意的是，这个角色报告自己只是 R；同样，没有涉及方括号。

接下来，你可能已经知道，在 Raku 中，同一个角色有可能有不同的变体。

⇒ raku -e 'role R[::T] { }; role R { }; say R.WHAT'
(R)

我们有两个声明，但仍然只使用 R 来调用 WHAT。

让我们换个角度，看看这个角色是如何实现的。

⇒ raku -e 'role R[::T] { }; say R.HOW.^name'
Perl6::Metamodel::ParametricRoleGroupHOW

注意名字中的 Group 部分。新手可能会对这个词感到困惑，只要他们只使用一个角色的变体。但是当他们到了本节第二个例子的时候，事情就开始变得比较清楚了。让我再把它们变得更加混乱。

role R[::T] { method foo { 42 } }
role R { }
say R.^lookup('foo');

你希望这段代码能输出什么？根据文档，在一个类上这样做会得到相当可预测的结果。

class Foo { method foo { } }; 
say Foo.^lookup("foo"); # foo

现在，忘记这个经验吧。因为对于上面的例子中的 R，我们会得到 (Mu)，意思是没有找到方法！而对于 R，我们会得到 (Mu)。

在这一点上，我想退一步说。如果你读了 Raku 的文档或书，做了关于角色和参数化的部分，有一个细节可能会让你觉得相当熟悉。如果这也是我要指出的"东西”，那么你就不会错了：参数化是关于参数的；有了参数，就有了签名！"。现在这段代码一定是完全有意义的。

role R[Int:D $a, Str:D $b] { ... }

角色声明中被方括号括起来的部分是一个签名，这有另一层意思，我将在后面再谈。

不幸的是，我在写这篇文章的时候有点超时，它应该在涉及到几个更基本的主题之后再完成。出于这个原因，我为下面的一点离题而道歉。

多重分派 #

人们可以在 Raku 文档中找到这一部分。另一节阐述了其语法和功能。但我想简单地谈谈这个功能的内部实现。让我们从一个基本的声明开始。

proto foo(|) {*}
multi foo(Int:D $i) {}
multi foo(Str:D $s) {}
say &foo.raku; # proto sub foo (|) {*}

正如你所看到的，raku 方法只报告了 proto。另外，如果我们对 &foo 调用 is_dispatcher 方法，它将返回 True。好的，但是这两个 multi 在哪里，当我们调用 foo("bar") 时会发生什么？用两句话来说，Raku 首先会找到 proto 方法。如果它通过检查 is_dispatcher 的返回值识别出它是这样的，那么它就会通过调用 &foo.candidates 来获取已知的候选列表。

say &foo.candidates.map(*.raku).join("\n");
# multi sub foo (Int:D $i) { #`(Sub|140560053018928) ... }
# multi sub foo (Str:D $s) { #`(Sub|140560053019072) ... }

然后，它试图将提供的参数与每个候选者的签名绑定。如果绑定成功，则调用该候选程序（如果没有找到，则抛出一个异常）。

显然，在现实生活中，事情要复杂得多，但我们还不需要知道这些……

回到多重角色的问题上 #

有时我对不能在文章的纯文本中递归到一个子主题感到奇怪。就把这一节的标题看成是上一节的 return 语句……啊，算了！不说了。

好吧，我的观点是什么，就是要讲述多重调度的故事？当我们看到 R.HOW 在类名中报告了一个 Group，就可以和多重调度实现中的 proto 相提并论了。事实上，我们调用 HOW 方法的类型对象 R 是一个伞状的实体，在其共同的名字下代表了角色的所有变体。而且，当我们把 R[Int] 应用于一个类时，实际发生的过程是一种多重分派，Raku 试图把方括号中的参数与角色候选者的签名相匹配。类似于我们如何列出 &foo 的候选者，我们也可以列出 R 的候选者。

``raku say R.^candidates.map(*.^name).join(", “); # R, R


唯一不同的是，这次我们使用了一个元方法 `.^candidates`。

在这一点上，还有一个谜团没有被揭开。还记得使用 `.^lookup` 的那个例子吗？为什么它不能找到这个方法？

`Perl6::Metamodel::ParametricRoleGroupHOW` 所支持的类型对象并不是一个我们可以实际使用的角色。它既没有方法也没有属性。然而，在某些情况下，我们可能希望它假装是一个成熟的角色。为了做到这一点，它选择了一个候选角色作为默认角色，然后在其上重新分配外部请求。当有一个没有签名的候选者时（如我们的 `role R {}`），它就成为隐式默认。否则，第一个声明的有签名的候选者就会成为默认的候选者。

回到我们的例子，`R.^lookup('foo')` 失败了，因为 `role R {}` 没有声明一个有这个名字的方法。

### 第二步: 候选者

直奔主题，让我们对候选者本身进行自省。

```raku
say R.^candidates.map({ .HOW.^name }).join(", ");

这看起来一定很熟悉，只是我们加入了.HOW的调用。下面是我们用它得到的东西。

Perl6::Metamodel::ParametricRoleHOW, Perl6::Metamodel::ParametricRoleHOW

它看起来也很熟悉，除了……是的，在类名称中没有 Group，我想欢迎我们的第二种角色! 实际上，我们已经知道了。如果我像这样挥舞着我的手，让我的观众分心，用…

哎呀，最后一句话应该是落在另一个窗口里的! 对于你，我的观众，我还有一行代码。

role R {}.HOW.^name.say; # Perl6::Metamodel::ParametricRoleHOW

BTW，这是一个很好的例子，说明无处不在的 Raku 概念，即所有东西都是一个对象。甚至声明也是；而且，只是为了好玩。

{ say "foo" }.^name.say; # Block

但是我分心了…

所以，这里真正重要的是，当我们声明一个角色时，Raku 为我们创建一个 Perl6::Metamodel::ParametricRoleHOW 类的实例。每个声明都有一个独特的类的实例支持，它负责持有角色类型对象的每个细节。例如，要想知道它是否可以被参数化，可以这样做。

sub is_parameterized(Mu \r --> Bool) {
    ? r.^signatured
}
say is_parameterized(role R[::T] {}); # True
say is_parameterized(role R {}); # False

请注意，由于 signatured 是在 NQP 中实现的方法，它不知道高级类型，并返回0或1。有时情况会变得更糟糕。我上面提到的查找元方法实际上返回 nqp::null()，这是一种 VM 级的对象。它决不能出现在 Raku 上。因此语言把它变成了 Mu，这是最基本的 Raku 类。

关于 Perl6::Metamodel::ParametricRoleHOW，在这一点上没有什么可说的。但我们稍后会回到它上面去。

第三步: 不确定性 #

为了更接近我们的第三种角色，我们从下面这个片段开始。

role R1[::T Stringy, ::V] { method foo { "stringy" } }
role R1[::T Numeric, ::V] { method foo { "numeric" } }
my \r = role R2[::T] does R1[Int, T] { }

让我们自省一下 R1。

# We know there is only one role, 
# hence .head for prettier output
say r.^roles.map({ .^name ~ " of " ~ .HOW.^name }).head;
# R1[Int,T] of Perl6::Metamodel::CurriedRoleHOW

输出显示了两个明显的变化。首先，角色名称现在报告了它的参数。第二，元对象现在属于 Perl6::Metamodel::CurriedRoleHOW 类。这是 Rakudo 在幕后做的另一种"魔法”，我将在本节中披露。

在上面的例子中，R2 声明最引人注目的特点是什么？事实上，在它消耗 R1 的地方，我们只知道第一个参数，而第二个参数仍然是一个通用参数。为了表示这种情况，我们对角色的了解是不完整的，Rakudo 使用了柯里化的角色。

从起源的角度来看，柯里化角色与前两种角色的关键区别在于，没有办法声明一个角色。柯里化只能是一个组的参数化的结果。而且，实际上，我很清楚，正式的组在 Raku 语法中并没有表示。但是只要它作为第一个角色声明的结果出现，我们就可以说它是由它产生的。而柯里化则完全由参数化产生。

也许有些令人惊讶，但在所有参数都为编译器所熟知的情况下，也可以发现柯里化的存在。

say R2[Str].HOW.^name; # Perl6::Metamodel::CurriedRoleHOW

部分原因是，当我们使用这样的角色时，我们所需要的也许是一些内省、类型检查或任何其他不需要具体对象的操作。比如说。

sub foo(R1[Int, Str] $a) {...}

我们在这里需要的是 foo 参数，以通过对 R1[Int, Str] 的类型检查。因为柯里化会帮我们完成这个工作，所以 Rakudo 在这里使用它。

say &foo.signature.params[0].type.HOW.^name;
# Perl6::Metamodel::CurriedRoleHOW

这是因为:

say R2[Str] ~~ R1[Int, Str]; # True
say R2[Int] ~~ R1[Int, Str]; # False

但还有一个主要原因。它将在下一节中披露。

第4步: 具体性 #

任何角色的命运都是被一个类所吞噬。(BTW，这里的双关语也不例外。)现在是时候考虑这最后阶段了。

role R1[::T] { }
role R2[::T] { }
role R3 { }
class C does R1[Int] does R2[Str] does R3 { }

通过反省类，我们会遇到所有的老朋友。

say C.^roles
     .map({ .^name ~ " of " ~ .HOW.^name })
     .join("\n");
# R3 of Perl6::Metamodel::ParametricRoleGroupHOW
# R2[Str] of Perl6::Metamodel::CurriedRoleHOW
# R1[Int] of Perl6::Metamodel::CurriedRoleHOW

有趣的是，我们在这里发现了不同种类的角色的混合。其原因是浮在上面的：与 R3 相反，另外两个角色是参数化的。

但由于我喜欢迷惑听众，所以我要告诉你：这些其实不是这个类所建立的角色！这是另一个操作。

当然，这是另一种操作。完整的短语必须是使用这个。“不是直接使用的角色”。

当我们尝试另一种方法时，情况就会大不相同。

say C.^mro(:roles)
     .map({ .^name ~ " of " ~ .HOW.^name })
     .join("\n");
# C of Perl6::Metamodel::ClassHOW
# R3 of Perl6::Metamodel::ConcreteRoleHOW
# R2 of Perl6::Metamodel::ConcreteRoleHOW
# R1 of Perl6::Metamodel::ConcreteRoleHOW

.^roles 和 .^mro 的区别在于，前者为我们提供了用于声明类的内容；而后者则为我们提供了实际构建的内容。

正如 HOW 类的名字所暗示的，我们现在处理的是角色的具体表现。换句话说，这是一种所有细节都知道的角色，它们是为这个特定的类专门设计的。这里强调的是目的：这个过程被称为特化；而 specialize 是实现它的元模型方法的名称。

我还想提醒你一下上一节的最后一句话。为什么每当人们使用 R[Int] 或类似形式的角色参数化时，他们都要处理一个柯里化的角色，原因是完全的特化需要角色被消耗的类。稍后我将说明原因。

我们现在可以退一步，概述一下角色的生命周期。

  1. 一个 Perl6::Metamodel::ParametricRoleGroupHOW 被创建。
  2. 一个 Perl6::Metamodel::ParametricRoleHOW 被创建并添加到该组。
  3. 一个类被声明并 does 这个角色。编译器尝试对角色进行参数化，如果需要参数化，Perl6::Metamodel::CurriedRoleHOW 就会被创建；否则就会使用原来的 Perl6::Metamodel::ParametricRoleHOW。
  4. 参数化的结果被添加到类的角色列表中。
  5. 当类被组成时，所有在上一步中添加的角色都被赋予了各自的参数和类的类型对象。在这一点上，我们得到了由 Perl6::Metamodel::ConcreteRoleHOW 支持的角色类型对象，或者换句话说，角色具体化。
  6. 这些具体化被添加到类中。
  7. 具体化是通过将其属性和方法迁移到类的类型对象中来应用的。

值得注意的是，具体化被保留为独立的实体，与它们所产生的角色分开。这就是我们在上面通过使用 .^roles 和 .^mro 进行内省观察到的。它们也可以使用 .^concretizations 元模型方法来访问。

say C.^concretizations
     .map({ .^name ~ " of " ~ .HOW.^name })
     .join("\n");
# R3 of Perl6::Metamodel::ConcreteRoleHOW
# R2 of Perl6::Metamodel::ConcreteRoleHOW
# R1 of Perl6::Metamodel::ConcreteRoleHOW

在这一点上，有两个相当大的主题仍然故意不清楚：一个角色候选人是如何被选择的？ 以及特化是做什么的？第一个问题我也许可以或多或少地完整地介绍一下。第二个问题对本文来说太复杂了，但有几个关键点绝对值得一提。

第1a步: 选择 #

震惊一个无辜的读者在媒体中非常流行。虽然我勉强算是个记者，但只要我把这篇文章称为文章–我有什么资格打破规则？所以，请坐好，握紧你的大脑。

我们开始了……准备好了没有……真相即将揭晓！"。

角色是一种例程。

很好，开始了。我说了！我一直想说的!

说真的，正如经常发现的关于点击率的新闻一样，这并不完全是真的，但有一点是真的。我想让你考虑一个例子。

role R {
    say "inside the role";
}
module Foo {
    say "inside Foo";
}
class C {
    say "inside the class";
}
# inside Foo
# inside the class

我们只看到两行输出，让我们了解到类的声明与模块的行为是一样的。但不是角色。让我们在这个例子中再加一行。

R.^candidates[0].^body_block.(C);
# inside the role

为什么是这样，为什么我把 C 作为一个参数传递，我将在下面关于特化的部分尝试回答。

现在我建议对主体块进行内省，但首先要在上述片段中增加一个角色的变体。

my \r = role R[::T, ::V Numeric] { }
say r.^body_block.raku;
# multi sub (::$?CLASS ::::?CLASS Mu $, ::T Mu $, ::V Numeric $) { #`(Sub|94052949943024) ... }

现在有印象了吗？sub 前面的 multi 这个词说明了一切，我现在的工作已经减少到所需的最小的措辞。

当编译器建立一个角色组时，它也创建了一个多调度例程。在内部，它被称为选择器。在每一个新添加的参数化角色中，它的主体块（实际上是一个 multi sub）都会被抽取出来，并作为一个多重调度候选程序添加到选择器中。现在，当人们在他们的代码中写下像 R[Int, Str] 这样的东西时，编译器会做一个类似于选择多重调度例程候选者的过程。基于进程提供的主体块候选，它选择了该块所属的角色。

所以，现在当我们提到角色签名时，一定会有更多的意义。因为它是一个签名，作为一个事实。如果我把一个角色声明 role R[::T, ::V] {} 以某种更适合人类程序员阅读的方式重新表述，它可能看起来像。

声明一个候选角色 R，其主体为块sub (::T, ::V) {...}。

很好，我们现在已经解决了这个问题。但是，我细心的读者，是不是有什么事情困扰着你？上面的"类似"一词是不是意味着某种……呃……惊喜？好吧，不幸的是，候选的选择并不遵循完整的多重调度协议，因为它缺乏对命名参数的支持。这是由于类型参数化的低级实现的限制。这意味着下面的两个声明被认为是相同的。

role R[Int, Bool :$foo] {...}
role R[Int, Str:D :$bar] {...}

希望当新的分派机制到达 Raku 时，情况会有所改变，但我在此不做任何承诺。

与此同时，你仍然可以使用这些名字，只是不要依靠它们来唯一地识别你的角色候选人。

一个黑魔法塞恩斯 #

这其实与选择候选者无关，但我不能忍受不给你看一些棘手的东西。此外，在许多小说和童话故事中，黑魔法是一种可以让你实现目标的东西，但有一个附加的价格标签。有时这个标签是相当血腥的，但这不是我的情况。实际上，我的目标和代价是一样的：我想用不同的东西来吸引你。

这就是要施的法术。

use nqp;
my \r = role R[::T, ::V Numeric] { }
class C { }
my \tenv = r.^body_block().(C, Str, Int);
my \ctx = nqp::atpos(tenv, 1);
my \iter = nqp::iterator(ctx);
while iter {
    my \elem = nqp::shift(iter);
    say nqp::iterkey_s(elem), " => ", nqp::iterval(elem);
}

只要主体块是一个例程，显然我们可以自己调用它。为了理解剩下的几行和所有使用的 nqp:: ops，人们需要参考 NQP ops 文档。

总之，“咒语"产生的输出可能看起来像这样。

::?CLASS => (C)
$?ROLE => (R)
T => (Str)
$?CONCRETIZATION => (Mu)
$?PACKAGE => (R)
::?PACKAGE => (R)
V => (Int)
::?ROLE => (R)
$?CLASS => (C)
$_ => (Mu)

用两个字来说，角色体块返回一个包含两个元素的数组。第二个元素是符号名称到其具体值的映射。也就是说，在 => 箭头左侧的键中，你可以很容易地从角色签名中发现我们的 T 和 V 类型捕获；以及编译器常量，如 ::?CLASS 和其他。

总的来说，代码返回的东西被称为内部类型环境，并被用于另一种广泛采用的机制，即泛型实例化。但这个话题肯定远远超出了本文的目的。这里确实值得一提的是，所有包含在环境中的符号实际上都是角色体词法。例如，如果我们把我的 FOO = 42 加入到主体中，那么上面的输出就会有以下一行加入到其中。

FOO => 42

另外，看着这些符号，你现在甚至可以更好地理解为什么角色的特化需要一个类来消耗它。你下次在做类似的事情时可能会考虑到这一点。

method foo(::?CLASS:D: |) {...}

最后我想指出的一点是 $?CONCRETIZATION 符号，它还没有被记录下来。它只在角色主体和角色方法中可用，并且当它可用时被绑定到角色的具体化中。这个符号主要是用于自省的目的。

步骤4a: 特化 #

所以，我们有一个候选者。我们知道具体的参数。我们知道消耗它的类。因此，我们确实知道了一切，可以进行特化，并得到具体化，最终将这个角色纳入消费它的类中。

正如我在上面已经提到的，特化是一个相当复杂的过程。在 Rakudo 元模型的实现中，它分布在几个源文件中，并涉及到一些其他的内部机制，如通用实例化，我在上面也暗示过。我最好不要深究其中的细节，而是专注于主要的阶段。那些真正好奇的人可以从 Rakudo 编译器源文件 src/Perl6/Metamodel/ParametricRoleHOW.nqp 中的方法特化开始。

特化一个新的角色，首先要创建一个 Perl6::Metamodel::ConcreteRoleHOW 的新实例和相应的具体角色类型对象。然后调用 body block 来获得一个类型环境结构。我将重点介绍一下这个。像往常一样，我们先举一个例子。

role R {
    say "inside the role, class is ", ::?CLASS.^name;
    say "class is composed? ", ::?CLASS.^is_composed ?? "yes" !! "no";
}
class C1 does R { }
class C2 does R { }
# inside the role, class is C1
# class is composed? no
# inside the role, class is C2
# class is composed? no

我们在这里观察到的是，角色主体已经被调用了两次，它知道它所应用的类，而且这个类还没有被组成（我在另一篇文章中介绍了一些关于类生命周期的信息）。另外，正如我已经提到的，具体化在这一点上存在。

role R {
	say $?CONCRETIZATION.^name; # R
}

但它还是空的。

say $?CONCRETIZATION.^attributes.elems; # 0
say $?CONCRETIZATION.^methods.elems;    # 0

而且，很明显，没有组成。

say $?CONCRETIZATION.^is_composed ?? "yes" !! "no"; # no

所有这些使得角色体成为一个好地方，可以在角色被实际消费时做需要做的事情。

现在，有了所有必要的信息，元模型通过实例化原始参数化或柯里化角色的属性和方法，并将它们安装到新创建的具体化中来最终完成专业化。例如这个片段的例子。

role R[::T] { has T $.attr }
class C R[Str] { }

如果我们转储原始角色和具体化的属性，我们可能会看到类似于下面的输出。

role attr: (Attribute|94613946040184 T $!attr)
concretization attr: (Attribute|94613946043184 Str $!attr)

当用属性和方法完成时，任何被消耗的角色都会被实例化和具体化。例如，对于这个声明。

role R1[::T, ::V] does R2[::T] { ... }

R2 的具体化将被添加到 R1 的具体化中，然后 R2 的具体化将被添加到 R1 的具体化中。

最后，如果有任何父类添加到角色中，它们也会被实例化和添加。

当所有上述准备工作完成后，我们的具体化就被组成了。它现在已经准备好被添加到它的消费类中。

故事就这样结束了。

偿还债务 #

知道很久以前的承诺最终得到了兑现，真的让人松了一口气。不幸的是，为了涵盖这个主题，我已经跳过了其他一些更基本的主题。例如，让读者更好地了解多重调度、类型对象的组成，以及 Rakudo、NQP 和后端虚拟机是如何相互作用的，这对读者是有益的。如果我写了足够多的文章，并考虑把这些材料编成一本书，那么由这段文字组成的章节将被放在离书的开头更远的地方。

不管怎么说，我已经尽了最大的努力，远离那些还未被提及的概念，希望你在这里找到有用的信息。

原文链接: https://vrurg.github.io/arfb-publication/07-roles-or-when-one-is-many/