动态语言中语义分析器的工作是什么？
请原谅我的英语。我最近试图了解编译器的不同部分并使用 play 语言来实现它们。我想知道语义分析器的工作是什么，因为我读到的语义分析器应该做的许多事情并不是真正适用于动态语言，例如类型检查、范围检查等，因为这些事情是在运行时检查的时间。
所以我认为动态语言（如 LUA 或 PYTHON 或 RUBY）的语义分析器的一些工作是
- 确保分配不坏，如 1 = a 或 5 = 5
但是，我不确定还有什么其他工作动态语言编译器的语义分析阶段是。在动态语言中，它的工作量似乎很小，因为大部分工作都是在运行时完成的。语义分析器还为动态语言处理哪些其他常见工作？我觉得我错过了语义分析的大部分内容。谢谢。
Pardon my english. I am recently trying to understand the different parts of a compiler and to implement them with a play language. I am wondering what the jobs of a semantic analyzer is, because many things that I read that a semantic analyzer is supposted to do are not really for dynamic languages, such as type checking, scope checking, etc. because those things are checked at run time.
So I think a few of the jobs of a semantic analyzer for a dynamic language (like LUA or PYTHON or RUBY) are to
- make sure that assignments are not bad like 1 = a or 5 = 5
However, I am not sure what other jobs the semantic analasis phase of a compiler for dynamic languages are. It seems that it has a very small job to do in dynamic languages because most is done at run time. What other common jobs does the semantic analyzer take care of for dynamic languages? I feel as I am missing much of the part of semantic analasis. Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你是对的，动态语言编译器中不存在许多分析任务（这就是为什么它们实现起来相对简单）。不过，我还能想到其他一些任务：
范围界定。变量的类型甚至有时甚至是动态确定的存在是正确的，但至少对于 Lua 和 Python 来说，作用域的某些部分可以（并且如果您不想不必要地使实现复杂化的话应该）在编译时：非全局变量的作用域。
需要分析什么？这部分在 Lua 中很容易，因为有一个显式的
local关键字 - 但它仍然需要编译器知道它！ - 并且需要在 Python 中进行相对广泛的分析，通过隐式赋值使变量成为局部变量，并使用两个（在 3.x 中，在 2.x 中为一个）关键字来更改该行为。为什么这很重要？在 Python 中，访问尚未初始化的局部变量与访问 Python 中不存在的全局变量一样是错误，但错误不同。在Lua中，两者都会导致
nil和local都不会改变之前赋值的范围，但是后续读/写的语义仍然会改变。此外，这两种情况下的字节码指令也非常不同。优化。好吧，显然您只能获得有关变量/“常量”包含的内容的有限（如果有的话，在某些情况下）信息。尽管如此，至少 CPython 具有各种各样的常量折叠和字节码优化过程（请参阅 peephole.c），甚至 Lua 及其超快的一次性编译器也会对算术指令进行一些常量折叠。 PyPy 解释器（独立于其 JIT）引入了 < code>CALL_LIKELY_BUILTIN 为调用全局变量而发出的操作码，根据其名称，这些全局变量可能是内置函数。显然，这需要一些范围分析。
正如您自己所说，抱怨编译时禁止的少数构造。然而，这也可以在解析下计数（其中许多规则实际上是在语法中编码的）。另一个例子（在语法中不容易编码）是重复的函数参数名称。
You're right, many analysis tasks don't exist in dynamic language compilers (that's why they are relatively simple to implement). However, there are a few more tasks I can think of:
Scoping. It is correct that the type and sometimes even existence of variables is determined dynamically, but at least for Lua and Python, there is some part of scoping that can (and should if you don't want to complicate the implementation needlessly) be done at compile time: The scope of non-global variables.
What has to be analyzed? That part is easy in Lua as there is an explicit
localkeyword - but it still requires the compiler to be aware of it! - and requires relatively extensive analysis in Python, with assignments implicitly making variables locals and two (in 3.x, one in 2.x) keywords to change that behaviour.Why does it matter? In Python, acessing a local variable that hasn't been initialized yet is as much of an error as accessing a non-existing global in Python, but a different error. In Lua, both lead to
nilandlocaldoesn't change the scope of previous assignments, but the semantics of subsequent reads/writes still change. Also, the bytecode instructions for are very different in both cases.Optimizations. Well, obviously you can have only limited (if any, in some cases) information about what variables/"constants" contain. Nonetheless, at least CPython has a wide variety of constant folding and bytecode optimization passes (see peephole.c) and even Lua with its insanely fast one-pass compiler does some constant folding on arithmetic instructions. And the PyPy interpreter (independently of its JIT) introduced a
CALL_LIKELY_BUILTINopcode that's emitted for calls to globals that, by their name, are probably builtin function. It's obvious that this requires some scope analysis.As you said yourself, complaining about the few constructs that are forbidden at compile-time. However, this could be counted under parsing as well (many of these rules are actually encoded in the grammar). Another example (that aren't easily encoded in the grammar) is duplicate function parameter names.