如何构建同时支持REPL解释器与编译器的模块化解析器？

这确实是个非常实用的问题——把整程序编译和交互式REPL的解析逻辑统一起来，既能减少重复代码，又能保证语法一致性，我在做小型语言实现的时候也踩过不少坑，这里分享一套模块化的可行方案：

1. 从语法设计入手：区分顶层入口符号 #

你完全不需要为两种场景写两套语法，只需要在同一套语法规则里定义两个起始符号，让解析器根据场景选择入口：

• program：整程序编译的入口，对应完整的程序结构（比如包含所有顶层声明、语句块）
• repl_input：REPL的入口，支持单个顶层语句、表达式，甚至不完整的语法片段（比如未闭合的括号、多行函数定义的开头）

举个简化的语法例子（类似Bison语法风格）：

%start program repl_input

/* 整程序入口 */
program: top_level_decl_list ;

/* REPL入口：支持单个语句、表达式，或者不完整输入 */
repl_input: top_level_stmt
          | expression
          | incomplete_stmt  /* 匹配需要补全的语法片段 */
          ;

/* 共享的核心语法规则 */
top_level_decl_list: top_level_decl | top_level_decl_list top_level_decl ;
top_level_stmt: assignment_stmt | if_stmt | function_call_stmt ;
expression: literal | binary_expr | function_call_expr ;
/* ... 其他共享规则 ... */

/* 专为REPL定义的不完整规则 */
incomplete_stmt: if_stmt_head  /* 比如 "if (x > 0)" 未写后续语句块 */
               | function_def_head  /* 比如 "def foo(a, b)" 未写函数体 */
               ;

核心语法规则完全复用，只是通过不同的起始符号适配两种场景。

2. 改造LALR(1)解析器：支持状态保存与不完整输入判断 #

标准LALR(1)解析器是一次性处理所有token，要么成功解析到接受状态，要么报错。要支持REPL，需要做两个关键改造：

2.1 让解析器可暂停/恢复 #

把解析器的核心状态（状态栈、已规约的AST节点、当前token位置）封装成可序列化的结构，这样当REPL遇到不完整输入时，可以保存当前状态，等用户输入下一行后再恢复解析。

比如用Python实现的简化示例：

class LALRParser:
    def __init__(self, grammar):
        self.state_stack = [0]  # 初始状态
        self.ast_stack = []
        self.current_tokens = []
    
    def feed_tokens(self, tokens):
        self.current_tokens.extend(tokens)
        # 执行状态转移/规约逻辑，直到无法继续或遇到错误
    
    def save_state(self):
        return (self.state_stack.copy(), self.ast_stack.copy(), len(self.current_tokens))
    
    def restore_state(self, state):
        self.state_stack, self.ast_stack, token_pos = state
        self.current_tokens = self.current_tokens[:token_pos]

2.2 区分“语法错误”和“不完整输入” #

REPL中最容易混淆的两种情况：用户输入了无效语法，还是输入了一半的多行语句。你需要在解析器中加入判断逻辑：

• 当token流结束时，检查当前状态栈的顶部状态：如果该状态存在合法的后续token（即状态转移表中还有未尝试的token类型，且属于repl_input规则的后续符号），则判定为不完整输入，等待用户继续输入；
• 如果当前状态没有合法的后续token，或者遇到明确的语法冲突，则判定为语法错误，提示用户并重置解析器状态。

很多LALR生成器（比如Bison）支持自定义错误处理，你可以通过扩展错误处理函数实现这个逻辑：在REPL模式下，触发错误时先检查是否能接受更多token，再决定是报错还是等待输入。

3. 模块化架构：共享核心，适配场景 #

把整个解析流程拆成三个独立模块，实现最大程度的复用：

• 共享词法分析器（Lexer）：不管是编译器还是REPL，都用同一套词法规则生成token。注意处理换行符：如果语言语法不依赖换行（如C、Java），词法分析器可忽略换行；如果依赖（如Python），则需把换行符作为特殊token传递给解析器。
• 核心解析引擎：封装LALR(1)的状态转移、规约逻辑，接受token流和起始符号，返回三种结果：完整AST、需要更多输入的状态、语法错误。引擎设计为无副作用，所有状态通过实例变量保存或参数传递。
• 场景适配层：
  • 编译器适配：读取整个源文件的token，传入核心引擎，使用program作为起始符号，得到完整程序AST后，传递给编译器的语义分析、代码生成阶段。
  • REPL适配：逐行读取用户输入，生成token后传入核心引擎，使用repl_input作为起始符号：
    • 返回完整AST：求值并打印结果，重置解析器状态；
    • 返回需要更多输入：保存当前状态，提示用户继续输入（比如显示...）；
    • 返回语法错误：提示用户错误信息，重置解析器状态。

4. 实用技巧与注意事项 #

• 优先实现整程序解析：先确保整程序的语法规则和解析逻辑正确，再扩展REPL模式，减少调试复杂度。
• 处理REPL表达式求值：很多语言的REPL允许直接输入表达式（如1 + 2 * 3），你可以在repl_input规则中直接包含expression，并在语义动作中添加求值逻辑，而整程序中表达式通常需要包裹在语句中。
• 测试边界情况：比如多行函数定义、未闭合的字符串/括号、嵌套条件语句，确保解析器能正确识别不完整输入并等待用户补全。

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