上下文：
当我了解解析器时，编译代码的过程（比方说，C ++）解释如下：
Bret Victor想要一种编程环境，在您键入时评估代码。 （http://worrydream.com/#!/InventingOnPrinciple）
我猜他不是第一个，将这个概念转换为2D游戏编程以外的通用编程可能存在一些概念上的问题，我知道有些系统已经做了类似的事情：例如preadsheets（如Excel），Smalltalk。
这不是我想要讨论的内容。
问题:(种类广泛，抱歉 - 主要问题是粗体）
如何在编辑工作时解析文本？ 我有这个想法，每当编辑器发送一个事件表明文本的某些部分被更改时，只有一部分AST被重新评估，并且受AST部分影响的值也会被重新评估。
我考虑过编写一个解析器生成器，它像往常一样使用语法，但会生成一个解析器来处理文本的增量更改，而不是整个文本。
1。这是一个合理的概念吗？（对于任何模糊的编程语言/环境。可能是“功能反应”的东西。或者只是html。）
（2。）它甚至可以使用吗？
（3。）是否足够快地解析整个文件以使复杂的方法变得不必要？
（4。）Eclipse中的IDE中的语法高亮显示或类型检查是否像这样工作？他们是如何工作的呢？我认为它们没有编译器解析器那么强大，以使它们足够快地工作，是吗？
（5.）Stackoverflow中有一个样式文本的实时预览。每次按键后都会解析整个问题吗？是否有“我的”概念会解决的一些限制？
答案 0 :(得分：4)
tab-completion（或“intellisense”）需要一些非常类似于解析的东西，以便弄清楚合理的完成/后续可能是什么。您可能在某些IDE中有一些经验。如果是这样，你也会注意到它的一些局限性。
像SO的预览功能这样的系统会定期解析输入，但不一定会在每次击键时解析。您可能会注意到语法突出显示稍微滞后，特别是当缓冲区已满时。一个典型的策略是让一个进程反复重新分析，直到在解析过程中输入没有改变，然后等待下一次更改。
像vim和emacs这样的文本编辑器会对每次击键进行重新分析，但它们会通过在行尾（通常）缓存上下文来进行优化，因此重新分析仅限于几个字符。 （当然，他们没有完整解析，所以更容易。）
对抽象语法树的增量解析和就地编辑进行了一些研究，但它变得非常棘手。一种自然适合这种风格的解析策略是“packrat解析”（可以使用广泛的参考书目here）。
众所周知，C ++很难正确解析。实际上，弄清楚给定的<是模板括号还是小于号是非常重要的;一般来说，如果不读取所有头文件，就不能这样做，在某些情况下，如果没有实例化模板，你就无法弄明白;以交互方式做太多工作。许多其他语言更容易解析，并且定期重新解析的简单解决方案对于所有实际目的而言足够快。
希望能够解决您的大部分问题。
答案 1 :(得分：2)
这绝对是一个有趣的问题。我使用的解析器有点类似于我在GoWorks演示IDE中描述的解析器。这是一段视频，显示了解析器的运行情况（从5分钟开始）：
Intro to Tunnel Vision Labs' GoWorks IDE (Preview Release 7)
解析器不会每次解析整个文件，因为必要的解析信息只能从输入的子集派生。解析超过这个有几个缺点，包括以下主要项目。
据我所知，我们最新的IDE是唯一积极使用他们使用的特定解析器样式的IDE（这是您在IDE中设计的非常特定的子集）作为多语言的一般方法。
答案 2 :(得分：1)
主要通过以下两种方式之一完成：
Smalltalk当然只解析一个方法。这使得解决方案更快更简单，错误地解释得更少。打字时重新分配可能会受到限制。只要无法识别标识符，在它之后重新分析部分就没有多大意义。
很久以前，有一个用于mac（以及一个c）的think pascal编译器，它运行得非常好。