LR是什么：手写实现解析LR解析器底层逻辑

用户85086927615
0 阅读11分钟

LR是什么：手写实现解析LR解析器底层逻辑

学会语法却不知怎么搭项目，这是很多后端工程师的痛点。你背熟了Python或Java的类继承、接口定义，甚至能画出UML图，但一面对“编译器怎么知道代码该往哪走”这种问题就发懵。其实，解决这个问题的核心钥匙就是LR是什么以及手写实现一个最小可用的LR解析器。别被“编译器”这三个字吓退，LR（Leftmost derivation, Rightmost sentential form）解析器并不是高不可攀的黑盒，它是一套严密的数学逻辑，只要理清状态转换，你就能亲手搭建起一个能识别合法语法的引擎。

一句话原理：LR是“看后面决定前面”的左推导艺术

在深入代码之前，先厘清LR的本质。LR解析器是一种自底向上的语法分析方法。这里的“L”代表从左到右扫描输入符号串（Left to right），而“R”代表归约时选择最右逆向推导（Rightmost sentential form）。

很多人会混淆LL和LR。LL解析器是“自顶向下”，它看着当前的输入，猜测接下来该展开哪个产生式；而LR解析器更像一个严谨的侦探，它先拿着手里的“证据”（输入符号），一步步回溯，看这些证据能拼凑成哪个合法的“嫌疑人”（非终结符）。这种手写实现LR解析器的过程，本质上是在构建一个确定性的有限自动机（DFA），这个自动机根据当前栈顶的状态和下一个输入符号，决定是“移进”（Shift）还是“归约”（Reduce）。

理解LR是什么，关键在于理解LR(k)文法。通常我们使用LR(1)文法，即向前看一个符号就能做出决策。为什么需要向前看？因为有些语法结构是二义性的，或者存在冲突。比如if (a) if (b) c; else d;，这个else到底配哪个if？LR解析器通过查表，结合当前的状态和下一个字符，唯一确定动作，从而避免歧义。

类比解释：把语法分析比作“拼图游戏”

为了让你直观感受手写实现LR解析器的逻辑，我们用一个“拼图游戏”来类比。

想象你面前有一堆散乱的拼图块（输入符号），和一个已经铺好一部分底板的桌子（分析栈）。你的目标是将所有拼图块按规则拼成一幅完整的画（归约为起始符号）。

  1. 移进（Shift）：你拿起手里的一块拼图（读取一个输入符号），尝试放到桌面的某个空位（压入栈）。这时候你并不知道这块拼图最终属于哪一部分，你只是先放上去。

  2. 归约（Reduce）：当你发现桌面上连续的几个拼图块正好构成了一个已知的小图案（比如一个“窗户”），你就把它们合并成一个更高级的拼图块（非终结符），并退回到“窗户”被展开之前的状态。

  3. 接受（Accept）：当桌面上只剩下起始符号，且输入流为空时，拼图完成，解析成功。

  4. 错误（Error）：如果你拿起一块拼图，发现无论放在哪里都不符合规则，或者你试图合并的拼图块根本不存在，解析失败。

LR解析表就是这个游戏的“规则手册”。它是一个二维表格，行代表状态（当前桌面的拼图进度），列代表输入符号。表格里的每个格子写着具体的指令：“移进并进入状态5”、“归约为产生式A->BC并跳转到状态3”或“接受”。

在手写实现中，我们的核心任务就是生成这张表，并写一个循环去查表执行。这比LL解析器复杂的地方在于，LL只需要一个简单的栈来记录路径，而LR需要一个更复杂的栈来记录状态序列。

源码与伪代码：手写实现一个最小LR(1)解析器

理论讲再多，不如代码来得实在。下面我们用Python手写实现一个极简的LR(1)解析器框架。虽然完整的LR(1)表生成算法（如DFA构建、项目集族计算）非常复杂，但解析器的执行逻辑是通用的。我们先假设表已经生成好，重点看解析循环。

# 假设已生成的LR(1)解析表
# 结构: table[state][symbol] = action
# action类型: ('shift', next_state), ('reduce', production_index), ('accept', None), ('error', None)

def build_example_table():
    """
    构造一个简单的表达式文法的LR(1)表
    文法:
    0. E -> T
    1. T -> T + F
    2. T -> F
    3. F -> ( E )
    4. F -> id
    """
    # 这里为了演示，手动构造部分状态和动作
    # 实际项目中，这一步需要运行LR生成器
    table = {
        0: {'id': ('shift', 1), '(': ('shift', 2), '$': ('error', None)},
        1: {'$': ('reduce', 4), '+': ('reduce', 4), ')': ('reduce', 4)}, # F -> id
        2: {'id': ('shift', 1), '(': ('shift', 2)}, # F -> ( E
        3: {'+': ('shift', 4), '$': ('reduce', 0), ')': ('reduce', 0)}, # E -> T (after T)
        4: {'id': ('shift', 1), '(': ('shift', 2)}, # T -> T + F
        5: {'$': ('reduce', 2), '+': ('reduce', 2), ')': ('reduce', 2)}, # T -> F
        6: {'+': ('shift', 4), '$': ('reduce', 1), ')': ('reduce', 1)}, # T -> T + F
        7: {'$': ('reduce', 3), '+': ('reduce', 3), ')': ('reduce', 3)}, # F -> ( E )
        8: {'$': ('accept', None)} # Start state after E
    }
    return table

def lr_parse(input_string, table, productions):
    """
    手写实现LR解析核心循环
    :param input_string: 输入符号串，如 "id + id"
    :param table: LR解析表
    :param productions: 产生式列表
    :return: 解析结果或错误
    """
    stack = [0] # 状态栈，初始状态为0
    index = 0 # 输入指针
    input_symbols = input_string.split() + ['$'] # 添加结束符

    while True:
        state = stack[-1] # 当前状态
        symbol = input_symbols[index] # 当前输入符号

        if symbol not in table.get(state, {}):
            # 如果表里没这个符号，检查是否默认错误
            action = table.get(state, {}).get(symbol, ('error', None))
        else:
            action = table[state][symbol]

        action_type, action_val = action

        if action_type == 'error':
            return f"Syntax Error at '{symbol}'"

        elif action_type == 'shift':
            # 移进：将符号压入栈，状态切换到next_state
            stack.append(symbol)
            stack.append(action_val)
            index += 1 # 移动输入指针

        elif action_type == 'reduce':
            # 归约：弹出产生式右部的符号和状态，压入左部非终结符和新状态
            prod = productions[action_val]
            lhs, rhs = prod[0], prod[1]

            # 弹出右部符号对应的栈元素
            # 注意：每个符号对应一个状态，所以弹出2 * len(rhs)个元素
            for _ in range(len(rhs)):
                stack.pop() # 弹出状态
                stack.pop() # 弹出符号

            # 压入左部非终结符
            stack.append(lhs)

            # 查表获取归约后的新状态
            # 新状态由 (归约前栈顶状态, lhs) 决定
            prev_state = stack[-2]
            goto_state = table.get(prev_state, {}).get(lhs, ('error', None))
            if goto_state[0] != 'shift':
                # 简化处理，实际中goto表是独立的
                # 这里假设goto_state[1]是新状态
                pass
            # 在实际实现中，我们需要一个GOTO表，这里为简化略去复杂查找
            # 假设我们知道归约后进入哪个状态，这里直接模拟
            new_state = 3 if lhs == 'T' else 5 if lhs == 'F' else 8
            stack.append(new_state)

        elif action_type == 'accept':
            return "Parse Success"

# 产生式定义
productions = [
    ('E', ['T']),
    ('T', ['T', '+', 'F']),
    ('T', ['F']),
    ('F', ['(', 'E', ')']),
    ('F', ['id'])
]

# 测试
table = build_example_table()
result = lr_parse("id + id", table, productions)
print(result)

代码逐行解读：

  1. 状态栈（stack）：这是LR解析器的核心。它不存语法树，而是存状态编号。stack[-1]永远是当前解析进度所处的状态。

  2. 移进（Shift）：stack.append(symbol) 和 stack.append(next_state)。注意，我们同时压入了符号和状态，这样在归约时才能知道该符号在哪个状态下被移进，从而确定归约后的跳转状态。

  3. 归约（Reduce）：这是最复杂的一步。我们需要知道产生式右部有几个符号，然后从栈顶弹出对应数量的“符号+状态”对。弹出后，栈顶变成了产生式左部符号的“父状态”。我们需要查GOTO表，看“父状态”遇到“左部非终结符”时该跳到哪个新状态。

  4. 为什么需要向前看？ 在上面的简化代码中，我们没完全展示LR(1)的向前看逻辑。在实际的LR(1)表中，动作不仅取决于当前状态和输入符号，还取决于向前看符号（Lookahead）。例如，状态3遇到T，如果下一个是+，则归约为T->F；如果下一个是)，则归约为E->T。这就是LR(1)比SLR更强大的地方。

流程描述：从文法到解析动作的完整链路

手写实现LR解析器不仅仅是写那个while循环，更艰难的是生成解析表。这个过程涉及多个步骤，理解这个流程才能明白LR是什么的完整含义。

  1. 项目集族计算（Item Set Construction）： - 这是LR算法的心脏。我们需要为文法的每个非终结符扩展出“项目”（Item）。项目是在产生式右部插入一个点·，表示解析进度。 - 例如，产生式E -> T的项目有：E -> ·T 和 E -> T·。 - 通过闭包（Closure）和转换（GOTO）操作，我们构建出一系列状态，每个状态包含一组项目。

  2. DFA构建： - 每个项目集族就是一个DFA的状态。 - 从初始状态出发，根据输入符号进行GOTO转换，生成新的状态，直到没有新状态产生。

  3. 冲突检测与处理： - 移进-归约冲突：在当前状态，既可以移进下一个符号，也可以归约某个产生式。LR(1)通过向前看符号来区分：如果向前看符号属于归约产生式的Follow集，则归约；否则移进。如果冲突无法解决，文法不是LR(1)的。 - 归约-归约冲突：两个不同的产生式都想归约。LR(1)通常无法自动解决，需要修改文法。

  4. 生成解析表： - 对于每个状态和每个输入符号，根据项目类型填入动作。 - 如果项目是A -> α·β（移进项），则填入Shift。 - 如果项目是A -> α·（归约项），且向前看符号在Follow(A)中，则填入Reduce。

流程图示：

[文法]
   |
   v
[计算项目集族] --> [构建DFA状态]
   |
   v
[检测冲突] --(有冲突)--> [报错或修改文法]
   |
   v (无冲突)
[生成ACTION表] + [生成GOTO表]
   |
   v
[LR解析器执行] --> [输入串]
   |
   v
[输出: 语法树 或 错误位置]

实战验证：现场常见违规问题与合格标准

在实际的项目开发中，很多团队直接调用ANTLR或GCC的bison工具，但作为资深工程师，你必须理解手写实现背后的逻辑，以便在遇到奇怪解析错误时能快速定位。

现场常见违规问题：

  1. 文法二义性（Ambiguity）： - 现象：解析器报告“Shift/Reduce Conflict”。 - 原因：文法设计不好，比如if-else悬挂问题。 - 解决：修改文法，消除二义性。例如，将if语句拆分为if-then和if-else两种非终结符。

  2. 左递归（Left Recursion）： - 现象：LL解析器会死循环，但LR解析器通常能处理左递归。然而，如果左递归过于复杂，可能导致状态爆炸。 - 注意：LR解析器可以处理左递归，这是它相对于LL解析器的一个巨大优势。但在手写实现时，要确保项目集计算不会陷入死循环。

  3. 空产生式（Null Production）： - 现象：A -> ε。 - 处理：LR解析器需要特别处理空符号的归约。在解析表中，如果当前状态包含A -> ·且向前看符号允许，则立即归约为A -> ε，而不消耗输入。

合格标准与通过率：

  • 状态数量：对于中等规模的文法（如JSON、简单表达式），LR(1)的状态数通常在50-200之间。如果状态数超过500，说明文法可能过于复杂或存在不必要的冗余，建议优化文法或考虑使用LALR(1)（更紧凑但稍弱）。

  • 冲突数：合格的LR(1)文法应该零冲突。如果存在少量移进-归约冲突，可以通过定义优先级（Precedence）和结合性（Associativity）来解决，这在手写实现的扩展中很常见。

  • 解析速度：LR解析器是线性时间复杂度O(n)，这是它被广泛应用于编译器、数据库SQL解析、配置文件解析的原因。如果你的解析器速度慢，很可能是因为在手写实现中使用了低效的哈希查找或状态栈管理。

权威参考： 根据《Compilers: Principles, Techniques, and Tools》（龙书）开发者文档及ANTLR官方规范，LR(1)解析表的大小取决于文法的复杂度，但其解析效率是常数因子级别的。在实际工业界，如PostgreSQL的SQL解析器、GCC的C++解析器，都深度依赖LR/LALR逻辑。

总结： LR是什么？它是一套通过手写实现状态机来精确控制语法解析流程的算法。它不靠猜测，而是靠查表和向前看来做出确定性的决策。虽然手写实现一个完整的LR(1)生成器代码量巨大，但理解其执行逻辑（栈、表、循环）是每个资深开发者的必修课。

你公司项目里是怎么处理复杂语法解析的？是直接用ANTLR，还是手写实现了一个精简版的解析器？欢迎在评论区分享你的实战经验和踩坑记录。

本文参考文献： http://www.pgsm.cn/juejin-74ics8k3n0.html

avatar
文章
阅读
粉丝