此时句法糖通常被认为是语法糖 - 解析或后续步骤？ 或者在哪个时候最好这样做？
假设表达式'array[index]'是表达式'get_element(array,index)'的语法糖。
如果在解析过程中被识别 - 那么'array [index]'的解析树与'get_element（array，index）'相同
如果在后续步骤中被识别 - 'array [index]'的解析树与'get_element（array，index）'不同
答案 0 :(得分：1)
tl;博士：@rici已经给出了单行答案 - 我想从我自己构建解析器的经验中进一步扩展。
我曾经在一步中构建了从输入到AST的解析器。我不再这样做，因为它最终成为可维护性的噩梦。许多不同的任务 - 字符串识别，错误报告，上下文敏感的约束，树构造 - 被粉碎在一起，解析器变得完全混乱。测试和调试非常困难，并且进行更改并不好玩。另外，解析器和语法之间的对应关系（在我看来，这是基于语法的解析方法的一个非常有价值的特性）丢失了。
我目前的方法是构建完全（希望）与输入语法对应的解析器，并同时构建默认的CST（具体语法树）。是的，这意味着CST包括＆＃34;垃圾＆＃34; - 比如打开和关闭括号 - 但这意味着解析器不需要使用树来构建。
然后，在稍后的状态中，CST被转换为AST。如果存在任何上下文相关的约束（例如对象文字中的唯一键），我会尝试在这里检查它们（并保持它们 out 的解析器）。这一步是＆＃34;垃圾＆＃34; （即大括号等具体语法）被丢弃。这一步也是我想要任何具体语法糖的地方 - 事实上，我对句法糖的定义是出现在具体而不是抽象语法中的东西。
我将混乱分解为单个步骤时注意到的优点是解析代码更清晰，更短，更具说明性，并且事物更模块化（这意味着我可以改变CST的方式映射到AST而不必考虑解析代码）。
摘要：我在从具体语法转换为抽象语法时删除了语法糖 * ，即在AST中根本没有出现糖。
*：你对语法糖的定义可能有所不同。