什么时候可以使用解析器生成器？
我正在为我正在编写的网络应用程序编写一种简单的文本模板语言（想想谷歌的ctemplate）。完成后，它将仅包含少量可能的操作，简单的内容，例如“评估和执行”、“评估和打印”、“评估和转义 html”、“注释”。我本来想从头开始手写整个解析器，但我开始研究像 lex、flex 和 antlr 这样的解析器生成器。这些似乎超出了我简单语法所需的范围。所以问题是，什么时候可以使用解析器生成器？
I'm writing a simple text-template language for a web application I'm writing (think google's ctemplate). When finished, it'll feature only a small number of possible actions, simple stuff like "evaluate and execute", "evaluate and print", "evaluate and escape html", "comment". I was thinking of hand writing the whole parser from scratch, but I started looking at parser generators like lex, flex and antlr. These seem like way more than I need for my simple syntax. So the question is, at what point is it practical to use a parser generator?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
宜早不宜迟。如果您现在有一个简单的语法，那么使用解析器生成器就很容易。当您想要添加变量、循环和条件时，它会变得更容易。
但是等等！ - 没有理由发明自己的语言，除非它是非常特定于领域的语言，例如
eqn或TeX> 或分子建模语言。嵌入专门为此目的设计的语言会更好。 Tcl 是该领域的老卫士，Python 是一个强有力的竞争者。 Perl 也被设计为一种嵌入式脚本语言，但我认为它是一个糟糕的候选者，因为它可能会在用户手中产生非常“只写”的代码。语言设计很困难，排除所有繁琐的部分就更难了。使用 Python 和 Tcl，您可以决定向用户公开多少核心语言，并在您发现需要时开放封闭的部分。
我编写的第一个小语言（令人惊讶的是它仍在生产中使用）如果使用 Tcl 的话会好得多。
Sooner rather than later. If you have a simple syntax now, using a parser generator is easy. It makes it easier still when you want to add variables and loops and conditionals.
But wait! - There is little reason to invent your own language unless it is very domain specific like
eqnorTeXor molecular modeling languages. You are far better off embedding a language that was specifically designed for the purpose. Tcl is the old guard in that realm, with Python being a strong contender. Perl was also designed to be an embedded scripting language but I think it a poor candidate as it will likely yield very "write-only" code in the hands of your users.Language design is hard and smoking all the fiddly bits out is harder still. With both Python and Tcl you can decide how much of the core language to expose to your users and open up closed bits as you find a need for them.
The first little language that I wrote (which astonishingly is still in production use) would have been so much better had Tcl been there to use instead.
一方面，如果您没有使用这些工具之一的经验，并且您有时间，那么也许这是一个学习该用例的好机会。我想，如果您对这些工具有经验，您就会简单地使用它们，就像许多解析任务使用正则表达式一样。
另一方面，简单的解析器并不难做，甚至不难维护。我喜欢编写它们，当任务需要一个工具而不是工具时，我通常会接触它们（但我对这些工具不是很熟悉）。在许多情况下，我更喜欢简单的解析器而不是正则表达式，具体取决于任务。
On the one hand if you don't have experience with one of these tools, and you have the time, then perhaps this is a good opportunity to learn one for this use case. I would imagine that if you were experienced in these tools, you'd simply use them, much like many grab for a regex for many parsing tasks.
On the other hand, simple parsers aren't that hard to do, they aren't even that hard to maintain. I like writing them, and I typically reach out for them when the task needs one rather than a tool (but I'm not super familiar with the tools). In many cases I prefer a simple parser over regex, depending on the task.