上下文:
当我了解解析器时，编译代码(比如 C++)的过程是这样解释的:
- 在文件中编写代码并保存。
- 将文件放入编译器。
- 编译器首先将代码解析成抽象语法树，
- 然后生成机器码。
- 运行代码进行测试。
- 重复。
Bret Victor 想要一种在您键入时评估代码的编程环境。 ( http://worrydream.com/#!/InventingOnPrinciple )
我想他不是第一个，将这个概念转化为 2D 游戏编程以外的通用编程可能存在一些概念性问题，而且我知道有些系统已经在做类似的事情:例如电子表格(如 Excel)、Smalltalk。
那不是我想讨论的。
问题:(有点宽泛，抱歉 - 主要问题是粗体)
如何在编辑时解析文本？ 我的想法是，每当编辑器发送一个事件表明文本的某些部分已更改时，只有一部分 AST 会被重新评估，并且受这部分 AST 影响的值也会被重新评估。
我考虑编写一个解析器生成器，它像往常一样采用语法，但生成一个解析器来处理对文本而不是整个文本的增量更改。
<强>1。这是一个合理的概念吗？(对于任何晦涩的编程语言/环境。可能是“功能性 react ”。或者只是 html。)
(2.) 它甚至可能被使用了吗？
(3.) 解析整个文件的速度是否足以使复杂的方法变得不必要？
(4.) Eclipse 等 IDE 中的语法高亮器或类型检查器是这样工作的吗？他们是如何工作的？我认为它们没有编译器-解析器那么强大，无法足够快地运行，对吗？
(5.) Stackoverflow 中有样式文本的实时预览。它会在每次击键后解析整个问题吗？它是否有一些“我的”概念可以解决的局限性？
最佳答案
制表符补全(或“智能感知”)需要一些与解析非常相似的东西，以便找出合理的补全/后续可能是什么。您可能在某些 IDE 中对此有一些经验。如果是这样，您也会注意到它的一些局限性。
SO 的预览功能等系统会定期解析输入，但不一定在每次击键时解析。您可能会注意到语法突出显示有点滞后，尤其是在缓冲区已满时。一个典型的策略是让一个进程重复重新解析，直到输入在解析过程中没有改变，然后等待下一次改变。
像 vim 和 emacs 这样的文本编辑器会在每次击键时重新解析，但它们通过在行尾缓存上下文(通常)进行优化，因此只对少数字符进行重新解析。 (当然，他们不做完整的解析，所以更容易。)
已经对抽象语法树的增量解析和就地编辑进行了一些研究，但结果变得非常棘手。一种自然适合这种风格的解析策略是“packrat 解析”(可获得大量引用书目 here)。
众所周知，C++ 很难正确解析。事实上，要弄清楚给定的 < 是否存在并非易事。是模板括号或小于号；通常，如果不阅读所有头文件，您将无法做到这一点，并且在某些情况下，如果不实例化模板，您将无法弄清楚；以交互方式完成的工作量太大了。许多其他语言更容易解析，并且定期重新解析的简单解决方案对于所有实际目的来说都足够快。
希望这能解决您的大部分问题。
关于parsing - 是否有在您键入时解析的解析器？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14667969/