这是“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 针对无法识别的标识符的错误消息，当它被视为潜在的后声明例程时，可以说是 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示例省略了逗号，并且这些术语都是编译器无法识别为尚未声明/导入的每个有效标识符。
因此，编译器允许它们可能都是后声明的例程（稍后在源代码中声明的例程）：
foo; # compiler doesn't bail because...
sub foo {} # `foo` might be declared later
但是，如果/当编译器到达正在编译的单元的末尾并且未能找到它先前视为可能丢失/后声明的例程的声明时，它会意识到它需要编译失败并生成错误消息。
它相当简洁和神秘地解释了这一点：
Could not find symbol '&Packd' in 'Packr::D'
这里的一个关键问题是，它希望读者注意&，并理解出于某种原因，尽管源代码没有提到 ，但它正在寻找&，并且知道 Raku 如何支持后声明的例程，等等，并把 2和 2 一起说“哦，当然”。
但是如果你是新手呢？或者 JJ 被其他一些更深层次的问题分散了注意力？
也许您只是没有使用官方版本，而这最终让您感到困惑，和/或错误消息与分心相结合，也许没有任何问题需要回答。
但我更怀疑有，它只是在翻译成 SO 时丢失了。
看完这个例子，发现它有点欠缺，我现在将重点放在标题上：
我不能在一个包中创建嵌套包吗？
是的：
package Foo { package Bar {} }
say Foo::Bar; # (Bar)
嗯，是的，从某种意义上说，我将其发布为答案，并且所有答案都可能是可以接受的，但也许不是，因为我不确定问题是什么，以至于我最终以我的答案结束作为一个问题。:)
因此，为了确保它确实是一个可能可接受的答案，我将以这个想法结束，从某种意义上说，这是对一切事物都可接受的答案：新年快乐。:)
[1]引用最小的、可重复的示例：
...可重现——测试您将要提供的代码以确保它重现问题
当我在没有测试的情况下共享代码时，墨菲定律通常适用，通常是因为我非常有信心它很好，或者很匆忙。
我修复随后经常引起的问题的唯一方法是仔细测试我将要分享的代码，在将其粘贴到任何评论或答案中后，并在单击提交之前，即使我认为自我以来我没有更改任何内容最后编译并运行它，并在每次编辑后每次都执行此操作。
当然，这是一件苦差事，有些人会觉得不值得这么麻烦……