不仅对表达式使用优先级解析器?

发布于 2024-10-21 13:39:20 字数 104 浏览 1 评论 0原文

是否可以对简单的编程语言使用某种运算符优先级解析器或分流场算法?例如,如果该语言只有表达式、函数和变量声明。

这种方式有什么缺点和优点?它能比传统的 LL/LR 解析器快得多吗?

Is it possible to use some kind of operator-precedence parser or shunting-yard algorithm for simple programming language? For example, if this language have only expressions, functions and declarations of variables.

What are cons and pros of this way? Can it be much faster than traditional LL/LR parsers?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

So尛奶瓶 2024-10-28 13:39:20

要回答你的第一个问题,是的,可以将运算符优先级解析作为语言的一部分。如果您对此感兴趣,您应该查看 Pratt 解析器。这通常是自上而下解析的变体,因此它应该与其他解析选项处于相同的性能范围内。一般来说,我认为人们过于关心解析速度。编译器通常会花费大部分时间进行优化,在解析阶段花费几毫秒对我​​来说似乎不值得。

有一种语言,喜鹊 ,它已经实现了 Pratt 解析器。因此,最大的优势是他们在库而不是核心语言中定义了该语言的所有运算符。这使得核心语言极其紧凑且可扩展。但缺点是,这使得其他用户总是不得不想知道特定运算符的优先级是什么,因为通常的内置规范可能不适用。

To answer your first question, yes it is possible to do operator precedence parsing as part of the language. If you are interested in this you should look into Pratt parsers. This is usually a variant of top-down parsing so it should be in the same performance neighborhood as your other parsing options. Generally, I think people are overly concerned about parsing speed. A compiler is going to spend most of its time doing optimizations usually and sweating a few milliseconds on the parsing stage doesn't seem worth while to me.

There is a language, magpie, that has implemented a Pratt parser. So the big advantage is that they have defined all of the operators for the language in a library instead of the core language. This makes the core language incredibly compact and extensible. The downside though is this leaves other users always having to wonder what the precedence of a particular operator will be as the usual built-in norms may not apply.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文