语法糖的通常 AST 结果是什么？答案

【问题标题】：What is usual AST result of syntactic sugar?语法糖的通常 AST 结果是什么？
【发布时间】：2013-10-13 16:17:52
【问题描述】：

什么时候语法糖通常被识别为语法糖 - 解析或后续步骤？或者什么时候做比较好？

假设表达式'array[index]' 是表达式'get_element(array,index)' 的语法糖。

如果在解析过程中被识别 - 那么 'array[index]' 的解析树与 'get_element(array,index)' 相同
如果在后续步骤中被识别 - 'array[index]' 的解析树不同于 'get_element(array,index)'

【问题讨论】：

我怀疑是否有比“它取决于”更好的答案，但在这种特殊情况下，我会在解析中这样做。在许多情况下，树变换更复杂，您应该稍后再做。
您是在说“如果在解析过程中执行它很简单 - 在解析过程中执行它”？
如果做起来很简单，它不会干扰生成良好的错误消息、调试信息或高级优化等...在极限情况下，您可以考虑将编译脱糖到汇编语言，并且某些语言有一次性编译器，它们在解析过程中逐步完成所有这些。所以，正如我所说，这取决于。

标签： parsing syntactic-sugar

【解决方案1】：

tl;dr：@rici 已经给出了一个简单的答案——我想从我自己构建解析器的经验中对此进行一些扩展。

我曾经构建可以一步直接从输入到 AST 的解析器。我不再这样做了，因为它最终成为了可维护性的噩梦。这么多不同的任务——字符串识别、错误报告、上下文相关的约束、树的构建——被粉碎在一起，以至于解析器变得一团糟。测试和调试非常困难，而且进行更改并不有趣。此外，解析器和语法（在我看来，这是基于语法的解析方法的一个非常有价值的特征）之间的对应关系丢失了。

我目前的方法是构建与输入语法完全对应的解析器（希望如此），并同时构建默认的 CST（具体语法树）。是的，这意味着 CST 包含“垃圾”——比如左大括号和右大括号——但这意味着解析器根本不需要构建树。

然后，在稍后的状态中，CST 被转换为 AST。如果有任何上下文相关的约束（例如对象文字中的唯一键），我会尝试在此处检查它们（并将它们保留在解析器之外）。这一步是“垃圾”（即大括号等具体语法）被丢弃的地方。这一步也是我对任何具体语法糖进行脱糖的地方——事实上，我对语法糖的定义是出现在具体语法中而不是抽象语法中的东西。

我注意到将我的混乱分成单独的步骤的优点是解析代码更清晰、更短、更具声明性，而且更模块化（这意味着我可以更改 CST 映射到一个 AST，甚至不必考虑解析代码）。

总结：在从具体语法转换为抽象语法时，我删除了语法糖^*，即糖根本不会出现在 AST 中。

*：你对语法糖的定义可能不同。

【讨论】：