Perl6哈希意外扁平化问题：两种数据结构为何不相等？

咱们先直接拆解你遇到的核心问题：当你运行这个测试时：

perl6 -e 'use Test; is-deeply [ { a => "b" } ], [ { a => "b" }, ];'

测试失败，因为左边的数组是$[:a("b")]（一个包含单个Pair的数组），而右边的是$[{:a("b")},]（一个包含单个哈希的数组）——这根本不是同一类东西，自然不相等。

尾随逗号的双重身份：有时无意义，有时关键 #

你提到Perl 6里的尾随逗号和Perl 5一样“无意义”，这个说法在部分场景是对的，比如：

perl6 -e '[ 1 ].elems.say; [ 1, ].elems.say' # 输出1和1

这里的尾随逗号确实不改变数组的长度或内容，因为里面是单个简单值（数字），编译器能明确识别它是一个独立元素。

但在你的哈希例子里，尾随逗号的作用完全不同——它直接改变了Perl 6对{ ... }的解析方式：

• 当你写[ { a => "b" } ]时，数组构造器里的{ a => "b" }被解析为Pair列表构造器（类似用()包裹的列表），所以最终数组里直接包含的是:a("b")这个Pair，而不是哈希。
• 当你加上尾随逗号写成[ { a => "b" }, ]时，逗号告诉Perl 6：{ a => "b" }是一个独立的表达式，此时Perl 6会把它解析为哈希字面量，所以数组里包含的是一个哈希对象。

你后面的测试也验证了这个差异：

# 数组里是两个Pair，长度为2
perl6 -e '[ { a => "b", c => "d" } ].elems.say;' # 输出2
# 数组里是一个哈希，长度为1
perl6 -e '[ { a => "b", c => "d" }, ].elems.say;' # 输出1

和Great List Refactor的关联 #

你猜的没错，这确实和Perl 6的**Great List Refactor（GLR）**规则有关。GLR的核心目标是简化列表、数组和哈希的构造逻辑，减少歧义，但也带来了一些和Perl 5不同的解析行为：

在GLR之前的Perl 6版本里，{ ... }在列表上下文里默认会被解析为哈希，但GLR调整了这个规则：

• 当{ ... }出现在列表/数组构造器的顶层时，里面的key => value语法会被优先解析为Pair的列表（也就是扁平展开），而不是哈希——除非你明确告诉编译器这是一个哈希。
• 如果你想在数组里直接创建哈希而不被扁平，除了加尾随逗号，还可以用%()显式构造哈希：

  # 两种写法效果一致，数组里都是单个哈希对象
  [ { a => "b" }, ]
  [ %{ a => "b" } ]
  

总结一下 #

• 你看到的测试失败，本质是两个数组的内容完全不同：一个存单个Pair，一个存单个哈希。
• 尾随逗号在简单值场景无意义，但在{ ... }这种有歧义的构造里，是告诉Perl 6把它解析为哈希的关键信号。
• 这种扁平化行为是Great List Refactor的设计结果——当你在数组里写{ key1 => val1, key2 => val2 }时，Perl 6默认认为你想直接把这些Pair放进数组，而不是先包装成哈希。

内容的提问来源于stack exchange，提问作者Pawel Pabian bbkr