适合搭建符号表的舞台

Question

有什么理由在词法分析阶段开始构建符号表吗？

在flex & bison: Text Processing Tools 一书中，作者给出了一个词法分析器的例子，试图构建一个简单的符号表。以下代码中有一个解决方法，可以将符号定义与其引用区分开来：

/* declaration keywords */
auto |
char |
int  |
/* ... skip ... */
volatile { defining = 1; }

/* ... skip ... */

/* punctuators */
"{"|"<%"|";"
{ defining = 0; }

此解决方案不适用于更复杂的情况，例如int a = b, c = d;（符号c 不会被标记为定义）。除此之外，无法在词法分析器阶段处理嵌套范围。

在问题lex and yacc (symbol table generation) 中注意到从词法分析器访问符号表是常规的，但我仍然看不到优点以及为什么在词法分析器中内置的表可能在以后有用。

Answer 1

一个原因是内存管理。传统的做法是复制从词法分析器传递到解析器的令牌字符串（至少在标识符令牌的情况下），但标识符通常在源文本中出现不止一次，并且真正需要一个副本。

与其每次都执行复制，不如将字符串“实习”在标识符哈希表中，然后传递哈希表条目。这样，每个符号的第二次和后续出现不会产生任何动态分配。另外，整个字符串存储可以作为字符串表数据结构的一部分来保存，这样可以简化释放动态分配存储的逻辑。

这并不完全是一个符号表，因为它（还）不包含任何语义或范围信息。但字符串表当然可以是保存符号表的基本结构，至少足以成为“构建符号表的开始”。

在某些语言中——C 是典型的例子——词法分析器可能希望能够查阅符号表中的语义信息，因此共享可能更加交织在一起。但即使没有这种骇人听闻的技巧，共享基本索引机制也可能会被证明是有用的，并且不一定会破坏关注点分离的概念。