结合状态和令牌抛出。为什么？
Combining state and token throws. Why?
这个有效
sub test-string( $string )
{
my token opening-brace { \( };
my token closing-brace { \) };
my token balanced-braces {
( <opening-brace>+ ) <closing-brace> ** { [=10=].chars }
};
so $string ~~ /^ <balanced-braces> $/;
}
这个
sub test-string( $string )
{
state token opening-brace { \( };
state token closing-brace { \) };
state token balanced-braces {
( <opening-brace>+ ) <closing-brace> ** { [=11=].chars }
};
so $string ~~ /^ <balanced-braces> $/;
}
死于
No such method 'opening-brace' for invocant of type 'Match'
in regex balanced-braces at ch-2.p6 line 13
in sub test-string at ch-2.p6 line 17
in block <unit> at ch-2.p6 line 23
我更喜欢第二个版本，因为我认为第一个版本在每次调用函数时都必须设置 token 时效率很低。因此，如果这是真实代码而不是挑战条目，我必须将令牌（文件）设为全局。
为什么会发生这种情况？
TL;DR 我喜欢 。有一个解决方法（请参阅 1），但我认为不值得。我不认为普通的 my 是低效的（参见 2）。我认为使用 state 和 regex/method 应该在编译时被拒绝（参见 take 3 和 5）或者保持原样（参见 4）。除非你是一个编码天才，愿意说服 jnthn Rakudo 应该开始显着增加对延续的接触（见 take 5）。
为什么会发生这种情况？ （取 1 个）
"This" 不会这样写：
sub test-string( $string )
{
state &opening-brace = token { \( }
state &closing-brace = token { \) }
state &balanced-braces = token {
( <&opening-brace>+ ) <&closing-brace> ** { [=10=].chars }
}
so $string ~~ /^ <&balanced-braces> $/;
}
（在正则表达式调用中需要 & 让我有点吃惊。1）
为什么会发生这种情况？ （取 2 个）
为什么会发生什么？
I believe the first version is quite inefficient when it has to set up the tokens every time the function is called.
"believe"、"quite inefficient"、"set up the tokens"是什么意思？我会 期望 只编译一次正则表达式代码（如果每次都编译我会感到震惊）但没有进行分析以验证。
这让我想到了一系列问题：
您是否纯粹关心每次调用 test-string 函数时重新创建 3 个 lexpad 条目（&opening-parens 等；更一般地说，正则表达式的数量）所花费的时间？
您是否真的分析了 运行 您的原始代码并发现了重大问题？
在实际项目中你真的测量过并发现它是part of your "critical 3%"吗？
为什么会发生这种情况？ （取 3 个）
state 声明符对 sub 做了一件合理的事情——它产生了一个编译时错误：
state sub foo {} # Compile time error: "Cannot use 'state' with sub declaration"
state my sub foo {} # Compile time error: "Type 'my' is not declared"
但是使用一种方法（这是隐藏在正则表达式中的东西）它可以编译但没有任何用处：
state method foo {} # Compiles, but I failed to find a way to access `foo`
state regex bar {.} # Same
我查看了 Rakudo 的 GH 问题队列，但没有找到讨论任何类似上面最后两行代码的问题（与您的 token 案例基本相同）。也许人们没有注意到这一点，或者至少不觉得提交错误会有帮助？
为什么会发生这种情况？ （取 4 个）
所以你会 post 一个 SO 记录 state regex 应该在编译时被拒绝或做一些有用的事情。 @Scimon++ 会记录另一种看待事物的方式。还有我一些。
为什么会发生这种情况？ （取 5 个）
<Your Compiler Code Goes Here>
因为 Raku is our MMORPG. If you would prefer to see the state declarator do something useful when used with a routine declaration (presumably it should either produce a compile-time error, like it currently does with a sub, or do some fancy continuation thing within the constraint of the "scoped continuations" 在构建 Raku 的基础上），那么考虑到 Rakudo 编译器主要是用 Raku 编写的，这项工作似乎只有 "smop" 的距离。有人故意在 sub 上使 state 成为编译时错误，并且延续概念将是一个真正庞大的项目，所以我认为在未来几年内合适的事情（如果有的话）将是使方法或规则上的 state 也是编译时错误。
或者，也许更恰当地说，现在 SO 涵盖了这一点，并提供了备选方案（语法）和解决方法（采取 1），是时候进入下一个级别了...
脚注
1 见 。用 state 声明的正则表达式的行为似乎没有遵循我在该答案中引用的设计推测的直接阅读。至少我在那个答案中的以下叙述也是错误的...
"<bar> is as explained above. It preferentially resolves to an early bound lexical (my/our) routine/rule named &bar.
...因为在这个答案的 take 1 代码中，正则表达式调用必须以 & 为前缀才能工作。也许他们工作完全是偶然的。
这个有效
sub test-string( $string )
{
my token opening-brace { \( };
my token closing-brace { \) };
my token balanced-braces {
( <opening-brace>+ ) <closing-brace> ** { [=10=].chars }
};
so $string ~~ /^ <balanced-braces> $/;
}
这个
sub test-string( $string )
{
state token opening-brace { \( };
state token closing-brace { \) };
state token balanced-braces {
( <opening-brace>+ ) <closing-brace> ** { [=11=].chars }
};
so $string ~~ /^ <balanced-braces> $/;
}
死于
No such method 'opening-brace' for invocant of type 'Match'
in regex balanced-braces at ch-2.p6 line 13
in sub test-string at ch-2.p6 line 17
in block <unit> at ch-2.p6 line 23
我更喜欢第二个版本，因为我认为第一个版本在每次调用函数时都必须设置 token 时效率很低。因此，如果这是真实代码而不是挑战条目，我必须将令牌（文件）设为全局。
为什么会发生这种情况？
TL;DR 我喜欢 my 是低效的（参见 2）。我认为使用 state 和 regex/method 应该在编译时被拒绝（参见 take 3 和 5）或者保持原样（参见 4）。除非你是一个编码天才，愿意说服 jnthn Rakudo 应该开始显着增加对延续的接触（见 take 5）。
为什么会发生这种情况？ （取 1 个）
"This" 不会这样写：
sub test-string( $string )
{
state &opening-brace = token { \( }
state &closing-brace = token { \) }
state &balanced-braces = token {
( <&opening-brace>+ ) <&closing-brace> ** { [=10=].chars }
}
so $string ~~ /^ <&balanced-braces> $/;
}
（在正则表达式调用中需要 & 让我有点吃惊。1）
为什么会发生这种情况？ （取 2 个）
为什么会发生什么？
I believe the first version is quite inefficient when it has to set up the tokens every time the function is called.
"believe"、"quite inefficient"、"set up the tokens"是什么意思？我会 期望 只编译一次正则表达式代码（如果每次都编译我会感到震惊）但没有进行分析以验证。
这让我想到了一系列问题：
您是否纯粹关心每次调用 test-string 函数时重新创建 3 个 lexpad 条目（&opening-parens 等；更一般地说，正则表达式的数量）所花费的时间？
您是否真的分析了 运行 您的原始代码并发现了重大问题？
在实际项目中你真的测量过并发现它是part of your "critical 3%"吗？
为什么会发生这种情况？ （取 3 个）
state 声明符对 sub 做了一件合理的事情——它产生了一个编译时错误：
state sub foo {} # Compile time error: "Cannot use 'state' with sub declaration"
state my sub foo {} # Compile time error: "Type 'my' is not declared"
但是使用一种方法（这是隐藏在正则表达式中的东西）它可以编译但没有任何用处：
state method foo {} # Compiles, but I failed to find a way to access `foo`
state regex bar {.} # Same
我查看了 Rakudo 的 GH 问题队列，但没有找到讨论任何类似上面最后两行代码的问题（与您的 token 案例基本相同）。也许人们没有注意到这一点，或者至少不觉得提交错误会有帮助？
为什么会发生这种情况？ （取 4 个）
所以你会 post 一个 SO 记录 state regex 应该在编译时被拒绝或做一些有用的事情。 @Scimon++ 会记录另一种看待事物的方式。还有我一些。
为什么会发生这种情况？ （取 5 个）
<Your Compiler Code Goes Here>
因为 Raku is our MMORPG. If you would prefer to see the state declarator do something useful when used with a routine declaration (presumably it should either produce a compile-time error, like it currently does with a sub, or do some fancy continuation thing within the constraint of the "scoped continuations" 在构建 Raku 的基础上），那么考虑到 Rakudo 编译器主要是用 Raku 编写的，这项工作似乎只有 "smop" 的距离。有人故意在 sub 上使 state 成为编译时错误，并且延续概念将是一个真正庞大的项目，所以我认为在未来几年内合适的事情（如果有的话）将是使方法或规则上的 state 也是编译时错误。
或者，也许更恰当地说，现在 SO 涵盖了这一点，并提供了备选方案（语法）和解决方法（采取 1），是时候进入下一个级别了...
脚注
1 见 state 声明的正则表达式的行为似乎没有遵循我在该答案中引用的设计推测的直接阅读。至少我在那个答案中的以下叙述也是错误的...
"
<bar>is as explained above. It preferentially resolves to an early bound lexical (my/our) routine/rule named&bar.
...因为在这个答案的 take 1 代码中，正则表达式调用必须以 & 为前缀才能工作。也许他们工作完全是偶然的。