自定义静态类型语言：名称解析与字节码生成的单遍实现问询

1. 名称解析方案 #

对于支持函数、类型（structs）先使用后声明的静态类型语言，单遍完成名称解析几乎不可行。核心原因是：当遍历AST遇到对某个函数/类型的引用时，对应的声明节点可能还未被处理，此时无法确定该标识符的合法性、作用域及类型信息——而静态类型语言要求这些绑定工作必须在编译阶段完成。

你当前采用的双遍方案是行业内成熟且稳妥的选择：

• 第一遍：遍历AST，收集所有函数、类型的声明节点，构建包含嵌套作用域的符号表（scope table），记录每个标识符的名称、作用域、类型签名/结构等元数据；对于必须先声明后使用的变量，可同步标记其声明位置。
• 第二遍：再次遍历AST，将所有标识符引用绑定到符号表中对应的声明项，同时完成类型检查（比如函数调用参数与签名是否匹配）。

若想优化双遍流程，可考虑：

• 第一遍仅聚焦收集声明信息，跳过表达式、语句的细节处理，提升遍历效率；
• 第一遍同步构建嵌套作用域的层级结构，避免第二遍重复处理作用域逻辑。

2. 字节码生成方案 #

由于静态类型语言需要提前获取函数签名（参数数量、类型）、struct结构等信息来生成正确的字节码，双遍生成方案是更清晰、可控的选择：

• 第一遍：遍历AST收集函数、struct的声明，生成对应的函数对象（包含签名、字节码占位符）和struct元数据（字段类型、内存布局），存入全局/作用域的对象表中。
• 第二遍：遍历AST生成具体字节码，遇到函数调用时，直接从对象表中获取已生成的函数对象，生成参数入栈、调用指令等字节码。

若尝试单遍生成，需要引入占位符+回填机制：遇到未声明的函数调用时，先生成占位指令，记录该调用的位置、所需签名信息，等后续遍历到函数声明时，再回头替换占位指令为正确的调用字节码。但这种方案复杂度极高，尤其是处理嵌套作用域、重载函数时，需要维护大量回填列表，容易引入bug且调试难度大。相比之下，双遍方案逻辑更直观，更适合小型语言的实现。

CPython符号表实现片段翻译 #

符号表需要两次遍历才能确定每个名称的作用域。
第一遍通过symtable_visit_*函数从AST收集原始信息：比如某个名称是此处的参数、某个名称被使用但未在此处定义等。
第二遍在遍历第一遍创建的PySTEntryObjects时，分析这些收集到的信息。

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