Динамический против статического компилятора (JavaScript)

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

Например:

var myObj = {};

function configureObject() {
    if (something in the environment) {
        myObj.myfunc = function () {alert("Hi");}
    } else {
        myObj.myfunc = function () {document.write("Hello");}
    }
}

Теперь, когда-нибудь позже в коде, который вы вызываете myObj.myfunc();. Во время компиляции неизвестно, что такое myfunc и является ли это атрибутом myObj. Это должен быть поиск во время выполнения.

В другом примере возьмите эту строку кода:

var c = a + b;

Его средства полностью зависят от типов a и b, и эти типы не известны во время компиляции.

Если a и b оба числа, то это оператор сложения, а c будет числом.

Если a или b является строкой, тогда другой будет приведен к строке, а c будет строкой.

Вы не можете предварительно скомпилировать такую ​​логику в собственный код. Среда выполнения должна записать, что это запрос оператора сложения между этими двумя операндами, и она должна (во время выполнения) проверить типы двух операндов и решить, что делать.

Проблема с написанием статического компилятора JavaScript состоит в том, что в целом неразрешимо сложно определить, на какие объекты ссылаются в любой точке программы или какие функции вызываются. Я мог бы использовать тот факт, что JavaScript является динамическим, чтобы решить, какую функцию вызывать, на основе вывода некоторой машины Тьюринга. Например:

var functionName = RunTuringMachineAndReportOutputOnTape(myTM, myInput);
eval(functionName + "();");

На этом этапе, если у вас нет предварительных знаний о том, что такое myTM и myInput, доказуемо невозможно решить, какая функция будет вызвана при вызове eval, поскольку невозможно определить, что находится на Тьюринге. ленту машины, если она останавливается (вы можете уменьшить проблему остановки до этой проблемы). Следовательно, независимо от того, насколько вы умны и насколько хорош статический анализатор, который вы построите, вы никогда не сможете правильно статически разрешить все вызовы функций. Вы не можете даже связать набор функций, которые могут быть вызваны здесь, поскольку выходные данные машины Тьюринга могут определять некоторую функцию, которая затем выполняется указанным выше кодом.

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

V8 делает это. См. Компиляция JavaScript в собственный код с V8

В EcmaScript 3 и 5 нестрогих есть ряд недостатков, с которыми вы не сталкиваетесь в других динамических языках. Вы можете подумать, что оптимизировать компилятор для локальных переменных легко, но в языке есть крайние случаи, когда это не так, даже игнорируя интроспекцию области видимости eval.

Учитывать

function f(o, x, y) {
  with (o) { return x + y + z; }
}

когда звонят с

o = {};
o = { z: 3 };
o = { x: 1, z: 2 };
Object.prototype.z = 3, o = {};

и согласно EcmaScript 3,

x = (function () { return toString(); })()

должен давать совсем другой результат, чем

x = toString();

потому что EcmaScript 3 определяет запись активации как объект с цепочкой прототипов.