Почему компиляторы предпочитают лексические области видимости?

Я действительно думаю, что лексическая область видимости помогает компилятору и оптимизации. Хотя это зависит от того, что вы подразумеваете под помощью.

Лексическая или статическая область видимости позволяет компилятору проверять доступность переменной при локальной ссылке, то есть в ее лексическом контексте. Он должен находиться в области действия метода, ссылающегося на переменную.

Чтобы сделать это в средах с динамической областью видимости, необходимо учитывать все контексты вызова, поскольку функция знает все переменные, известные ее контексту вызова. Чтобы убедиться, что переменная доступна для ссылки, во время компиляции потребуется рекурсивный возврат всех вызывающих контекстов.

Поскольку это очень сложно, во время компиляции это будет пропущено, что приведет к возникновению исключений во время выполнения.

См. здесь. поиск в функции, вызвавшей локальную функцию, затем поиск в функции, вызвавшей эту функцию, и так далее вверх по стеку вызовов. «Динамический» относится к изменению, поскольку стек вызовов может меняться каждый раз, когда вызывается данная функция, и поэтому функция может обращаться к разным переменным в зависимости от того, откуда она вызывается.

Лексическая (или статическая) область видимости уменьшает количество информации, необходимой компилятору для правильного преобразования текста в код. Это может помочь при компиляции, поскольку компилятору не нужно добавлять дополнительную информацию, к которой нужно обращаться во время выполнения (как в случае с динамической областью действия). Для оптимизации компилятору не нужно учитывать переменные, которые могут существовать в других областях, поскольку вы можете обращаться либо к локальным переменным, либо к глобальным переменным, и ни к чему другому.

Лексическая область видимости не помогает компилятору и не оптимизирует код. Это решение языкового дизайна. Дополнительные пояснения см. в этом вопросе.

С динамической областью многие оптимизации невозможны, потому что вы не можете гарантировать ограничения, которые делают оптимизацию возможной.

Это особенно важно для динамических языков, которые не гарантируют размер хранилища или представления.

Например, компилятор для динамически типизированного языка может взять связанный список упакованных объектов и заменить его массивом 8-битных байтов без знака, если он сможет доказать, что элементы списка всегда будут целыми числами от 0 до 255. , Такого рода вещи легко доказать со статической областью видимости, если вы используете ее правильно, и это может привести к значительному увеличению как пространства, так и вычислительной эффективности.

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

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

В динамической области область действия переменной определяется во время выполнения. Если переменная, объявленная как int, используется в другом лексическом окружении, где переменная с тем же именем имеет тип float. Единственное, нужно было считать их двумя разными переменными, а это значит, что переменные должны нести информацию о типе, в большинстве статических систем типов информация о типах вообще не входит в объектный код. Программа будет просто скомпилирована только тогда, когда она сможет доказать, что ошибок типов не возникнет, и тогда, конечно, информация о типах больше не потребуется.

По этой причине динамические языки, которые имеют лексическую область видимости, часто должны использовать кучу, а не стек для выделения информации времени выполнения.