《现代编译器实现（虎书）》第4章为何使用fundecs而非fundec？

调整的核心原因 #

1. 适配Tiger语言的递归声明语义 #

Tiger语言有明确的语义要求：连续的类型声明、连续的函数声明属于同一个互递归块，块内的类型、函数可以自由互相引用，不需要提前声明。
如果你用最初的产生式写法，每个tydec、fundec都是独立的dec节点，语义分析阶段你需要额外遍历整个decs列表，手动把连续的同类声明合并成块才能处理互递归逻辑，开发成本很高。
新增tydecs、fundecs列表节点后，语法分析阶段就自动完成了连续同类声明的聚合，语义分析时拿到单个tydecs/fundecs节点就能直接处理整组互递归声明，逻辑大幅简化。

2. 对齐虎书定义的AST结构 #

第4章给出的A_FundecList、A_NametyList就是专门用来表示同类型声明列表的AST构造函数。调整后的产生式可以在归约阶段直接调用对应构造函数生成符合规范的AST节点，不需要额外做结构转换，后续的语义分析、中间代码生成逻辑都可以直接和书里的实现对齐，减少开发偏差。

关于你提到的语法冲突 #

你观察到的冲突确实存在，属于典型的移进/归约冲突：当解析器已经识别出一个fundec，下一个输入token仍是FUNCTION时，解析器有两个选择：

• 归约：把当前fundec归约为dec，加入上层decs列表
• 移进：读入下一个FUNCTION，继续归约出更长的fundecs列表
  而YACC/Bison等LALR解析器的默认规则是移进优先，刚好完全符合我们的需求：优先把连续的同类声明聚合成同一个列表节点，只有当下一个token不属于同类声明的起始token时，才会把聚合好的列表归约为dec。
  这种冲突是预期内的，不需要额外处理，默认行为完全符合设计目标，很多虎书的参考实现甚至会特意保留这个冲突，作为语法规则符合设计的校验标志。

内容的提问来源于stack exchange，提问作者Shore