Каковы задачи семантического анализатора в динамическом языке? - PullRequest
Новая
       107

Каковы задачи семантического анализатора в динамическом языке?

3 голосов
/ 25 августа 2011

Простите мой английский. Недавно я пытался понять различные части компилятора и реализовать их на языке воспроизведения. Мне интересно, каковы задачи семантического анализатора, потому что многие вещи, которые я прочитал, которые предполагается выполнять семантическим анализатором, на самом деле не относятся к динамическим языкам, таким как проверка типов, проверка области видимости и т. Д., Потому что эти вещи проверяются при запуске время.

Так что я думаю, что некоторые из заданий семантического анализатора для динамического языка (например, LUA или PYTHON или RUBY) относятся к

  1. убедитесь, что назначения не плохие, как 1 = а или 5 = 5

Тем не менее, я не уверен, какие еще задания выполняет фаза семантического анализа компилятора для динамических языков. Кажется, что в динамических языках он выполняет очень небольшую работу, потому что большая часть выполняется во время выполнения. Какие другие общие задачи выполняет семантический анализатор для динамических языков? Я чувствую, что мне не хватает большей части смыслового анализа. Спасибо.

1 Ответ

4 голосов
/ 25 августа 2011

Вы правы, многие задачи анализа не существуют в динамических языковых компиляторах (поэтому они относительно просты в реализации).Тем не менее, есть еще несколько задач, о которых я могу подумать:

  • Scoping.Правильно, что тип, а иногда и существование переменных определяется динамически, но, по крайней мере, для Lua и Python, есть некоторая область видимости, которую можно (и нужно, если вы не хотите усложнять реализацию без необходимости) делать ввремя компиляции: область действия неглобальных переменных.

    • Что необходимо проанализировать?Эта часть проста в Lua, поскольку существует явное ключевое слово local, но для этого все же требуется, чтобы компилятор знал об этом!- и требует относительно обширного анализа в Python, при этом присваивания неявно делают переменные локальными и два (в 3.x, одно в 2.x) ключевых слова, чтобы изменить это поведение.

    • Почему этоиметь значение?В Python доступ к локальной переменной, которая еще не была инициализирована, является такой же ошибкой, как и доступ к несуществующему глобальному в Python, но другой ошибкой.В Lua оба приводят к nil и local не изменяют область действия предыдущих назначений, но семантика последующих операций чтения / записи по-прежнему изменяется.Кроме того, инструкции для байт-кода очень различны в обоих случаях.

  • Оптимизации.Ну, очевидно, вы можете иметь только ограниченную (если есть, в некоторых случаях) информацию о том, что содержат переменные / «константы».Тем не менее, по крайней мере, CPython имеет широкий спектр проходов с постоянным сворачиванием и оптимизацией байт-кода (см. peephole.c ), и даже Lua с его безумно быстрым однопроходным компилятором выполняет некоторое постоянное сворачивание по арифметическим инструкциям.А интерпретатор PyPy (независимо от его JIT) ввел код операции CALL_LIKELY_BUILTIN, который генерируется для вызовов глобальных переменных, которые, по их имени, являются, вероятно, встроенной функцией.Очевидно, что это требует некоторого анализа области действия.

  • Как вы сказали сами, вы жалуетесь на несколько конструкций, которые запрещены во время компиляции.Тем не менее, это может учитываться и при разборе (многие из этих правил фактически закодированы в грамматике).Другой пример (который не легко закодировать в грамматике) - это дубликаты имен параметров функции.

...