我不能在一个内创建嵌套包吗？
Can I not create nested packages within one?
这是“lib/Packr.rakumod”:
unit package Packr;
our class Packd is export {}
our class D::Packd is export {}
our class B::Packd is export {}
这是packr.rakumod:
use Packr;
for (Packr::Packd Packr::B::Packd Packr::D::Packd ) -> \P {
say P.new().raku;
}
此错误为：
Could not find symbol '&Packd' in 'Packr::D'
无论我声明的顺序如何，或者我是否使用“U”而不是“D”，都没有关系。我会尝试使用其他字母组合，但除非我遗漏了一些明显的东西，或者输入了错误的东西，否则我真的很困惑。
如果我简单地删除 Packr::D::Packd，也会发生这种情况。看起来它在第一个错误之后就退出了，这似乎是迭代中的最后一个错误，出于某种原因。
这是我今年的第一个问题，祝大家新年快乐！
TL;DR Raku 针对无法识别的标识符的错误消息，当它被视为潜在的 post-declared 例程时，可以说是 LTA。 （我认为是。）除此之外，我不确定您的问题是什么，但无论如何都会尝试回答...
你的 lib/Packr.rakumod 例子？
如果将 is export 应用于多个导出，使得导出的符号相同，编译器应该在编译时退出：
class A::foo is export {} # would export `foo`
class B::foo is export {} # would export `foo`
显示：
A symbol 'foo' has already been exported
因此，如果您的 lib/Packr.rakumod 示例为您编译，我怀疑您的编译器搞砸了。也许您使用的不是官方版本？[1]
你的 packr.rakumod 例子？
如果在两个术语之间省略逗号，则除非第一个是尚未声明的有效标识符（在这种情况下，编译器假定它可能是稍后将在同一单元中声明的例程), 编译器在编译时退出:
for (1 2) {}
显示：
Two terms in a row
您的 packr.rakumod 示例省略了逗号，并且这些术语都是编译器无法识别为尚未声明/导入的每个有效标识符。
所以编译器允许它们可能都是post-declared例程（稍后在源代码中声明的例程）：
foo; # compiler doesn't bail because...
sub foo {} # `foo` might be declared later
但是 if/when 编译器到达正在编译的单元的末尾并且未能找到它之前视为可能 missing/post-declared 例程的声明，它意识到它需要失败编译并生成错误消息。
它相当简洁和隐晦地解释了这一点：
Could not find symbol '&Packd' in 'Packr::D'
这里的一个关键问题是它希望 reader 关注 &，并理解出于某种原因它正在寻找它，尽管源代码没有提到 &，知道Raku如何支持post-declared例程等等，把2和2放在一起说“哦，当然了”。
但是如果您是新手怎么办？或者 JJ 被其他更深层次的问题分心了？
那么，你的问题是什么？
也许您只是没有使用官方版本，这最终让您感到困惑，and/or这是错误消息加上分心，也许没有任何问题需要解决已回答。
但我更怀疑有，它只是在 运行 变成 SO 的过程中丢失了。
看完这个例子，发现它有些欠缺，我现在将重点放在标题上：
Can I not create nested packages within one?
是：
package Foo { package Bar {} }
say Foo::Bar; # (Bar)
这是一个可以接受的答案吗？
嗯，是的，从某种意义上说，我把它作为一个答案发布了，所有的答案都可能是可以接受的，但也许不是，因为我不确定问题是什么，以至于我已经结束了最后我的回答是一个问题。 :)
因此，为了确保它确实是一个可能可以接受的答案，我将以这个想法结束，从某种意义上说，这是对所有事情都可以接受的答案：新年快乐。 :)
脚注
[1] 引用 Minimal, Reproducible Example:
...Reproducible -- Test the code you're about to provide to make sure it reproduces the problem
墨菲定律在我未经测试就共享代码时经常适用，通常是因为我非常有信心它没问题，或者很匆忙。
我解决通常引起的后续问题的唯一方法是仔细测试我将要分享的代码之后将它粘贴到任何评论或答案中，然后在点击提交之前，即使我认为自从我上次编译以来我没有改变任何东西并且运行 它，并在每次编辑后 执行此操作 .
当然，这是一件苦差事，有些人会觉得不值得这么麻烦...
这是“lib/Packr.rakumod”:
unit package Packr;
our class Packd is export {}
our class D::Packd is export {}
our class B::Packd is export {}
这是packr.rakumod:
use Packr;
for (Packr::Packd Packr::B::Packd Packr::D::Packd ) -> \P {
say P.new().raku;
}
此错误为：
Could not find symbol '&Packd' in 'Packr::D'
无论我声明的顺序如何，或者我是否使用“U”而不是“D”，都没有关系。我会尝试使用其他字母组合，但除非我遗漏了一些明显的东西，或者输入了错误的东西，否则我真的很困惑。
如果我简单地删除 Packr::D::Packd，也会发生这种情况。看起来它在第一个错误之后就退出了，这似乎是迭代中的最后一个错误，出于某种原因。
这是我今年的第一个问题，祝大家新年快乐！
TL;DR Raku 针对无法识别的标识符的错误消息，当它被视为潜在的 post-declared 例程时，可以说是 LTA。 （我认为是。）除此之外，我不确定您的问题是什么，但无论如何都会尝试回答...
你的 lib/Packr.rakumod 例子？
如果将 is export 应用于多个导出，使得导出的符号相同，编译器应该在编译时退出：
class A::foo is export {} # would export `foo`
class B::foo is export {} # would export `foo`
显示：
A symbol 'foo' has already been exported
因此，如果您的 lib/Packr.rakumod 示例为您编译，我怀疑您的编译器搞砸了。也许您使用的不是官方版本？[1]
你的 packr.rakumod 例子？
如果在两个术语之间省略逗号，则除非第一个是尚未声明的有效标识符（在这种情况下，编译器假定它可能是稍后将在同一单元中声明的例程), 编译器在编译时退出:
for (1 2) {}
显示：
Two terms in a row
您的 packr.rakumod 示例省略了逗号，并且这些术语都是编译器无法识别为尚未声明/导入的每个有效标识符。
所以编译器允许它们可能都是post-declared例程（稍后在源代码中声明的例程）：
foo; # compiler doesn't bail because...
sub foo {} # `foo` might be declared later
但是 if/when 编译器到达正在编译的单元的末尾并且未能找到它之前视为可能 missing/post-declared 例程的声明，它意识到它需要失败编译并生成错误消息。
它相当简洁和隐晦地解释了这一点：
Could not find symbol '&Packd' in 'Packr::D'
这里的一个关键问题是它希望 reader 关注 &，并理解出于某种原因它正在寻找它，尽管源代码没有提到 &，知道Raku如何支持post-declared例程等等，把2和2放在一起说“哦，当然了”。
但是如果您是新手怎么办？或者 JJ 被其他更深层次的问题分心了？
那么，你的问题是什么？
也许您只是没有使用官方版本，这最终让您感到困惑，and/or这是错误消息加上分心，也许没有任何问题需要解决已回答。
但我更怀疑有，它只是在 运行 变成 SO 的过程中丢失了。
看完这个例子，发现它有些欠缺，我现在将重点放在标题上：
Can I not create nested packages within one?
是：
package Foo { package Bar {} }
say Foo::Bar; # (Bar)
这是一个可以接受的答案吗？
嗯，是的，从某种意义上说，我把它作为一个答案发布了，所有的答案都可能是可以接受的，但也许不是，因为我不确定问题是什么，以至于我已经结束了最后我的回答是一个问题。 :)
因此，为了确保它确实是一个可能可以接受的答案，我将以这个想法结束，从某种意义上说，这是对所有事情都可以接受的答案：新年快乐。 :)
脚注
[1] 引用 Minimal, Reproducible Example:
...Reproducible -- Test the code you're about to provide to make sure it reproduces the problem
墨菲定律在我未经测试就共享代码时经常适用，通常是因为我非常有信心它没问题，或者很匆忙。
我解决通常引起的后续问题的唯一方法是仔细测试我将要分享的代码之后将它粘贴到任何评论或答案中，然后在点击提交之前，即使我认为自从我上次编译以来我没有改变任何东西并且运行 它，并在每次编辑后 执行此操作 .
当然，这是一件苦差事，有些人会觉得不值得这么麻烦...