在什么时候语法糖通常被认为是语法糖 - 解析或后续步骤？或者在什么时候这样做更好？
假设 expression'array[index]'是 expression 的语法糖'get_element(array,index)'。
如果在解析过程中被识别 - 那么“array[index]”的解析树与“get_element(array,index)”相同
如果在后面的步骤中识别 - 'array[index]' 的解析树与 'get_element(array,index)' 不同
问问题
207 次
1 回答
1
tl;dr：@rici 已经给出了一个简单的答案——我想从我自己构建解析器的经验中对此进行一些扩展。
我曾经构建过一个解析器，可以在一个步骤中直接从输入到 AST。我不再这样做了，因为它最终成为了可维护性的噩梦。这么多不同的任务——字符串识别、错误报告、上下文相关的约束、树的构建——被打碎在一起，以至于解析器变得一团糟。测试和调试非常困难，而且进行更改并不有趣。另外，解析器和语法之间的对应关系（在我看来，这是基于语法的解析方法的一个非常有价值的特征）丢失了。
我目前的方法是构建与输入语法完全对应的解析器（希望如此），并同时构建一个默认的 CST（具体语法树）。是的，这意味着 CST 包括“垃圾”——比如开括号和闭括号——但这意味着解析器根本不需要进行树构建。
然后，在稍后的状态中，CST 被转换为 AST。如果有任何上下文相关的约束（例如对象文字中的唯一键），我会尝试在这里检查它们（并将它们排除在解析器之外）。这一步是丢弃“垃圾”（即大括号等具体语法）的地方。这一步也是我对任何具体语法糖进行脱糖的地方——事实上，我对语法糖的定义是出现在具体语法中而不是抽象语法中的东西。
我注意到将我的混乱分成单独的步骤的优点是解析代码更干净、更短、更具声明性，而且事情更加模块化（这意味着我可以更改 CST 映射到 AST 的方式，而无需甚至不得不考虑解析代码）。
总结：在从具体语法转换为抽象语法时， 我删除了语法糖*，即糖根本没有出现在 AST 中。
*：您对语法糖的定义可能不同。
于 2013-10-14T15:44:40.883 回答