т.е. объект вызова – это некая процедура как продукт конкретной реализации, которая:
1. запускается при вызове функции, например, F();
2. создает контекст исполнения и его свойства: this, AO/VO, Scope;

так?

Да, именно так.

когда же функция вызывается с ‘new’ new F(), то происходит:
1. Вызов свойства констракт, которое создает native объект;
2. И в последствии вызывается внутреннее свойство call, где опять таки происходит создание контекста исполнения функции с его свойствами, где this уже будет указывать на новый созданый объект в шаге 1, где и происходит его инициализация;

Да, тоже все верно.

т.е. объект вызова – это некая процедура как продукт конкретной реализации, которая:
1. запускается при вызове функции, например, F();
2. создает контекст исполнения и его свойства: this, AO/VO, Scope;

так?

когда же функция вызывается с ‘new’ new F(), то происходит:
1. Вызов свойства констракт, которое создает native объект;
2. И в последствии вызывается внутреннее свойство call, где опять таки происходит создание контекста исполнения функции с его свойствами, где this уже будет указывать на новый созданый объект в шаге 1, где и происходит его инициализация;

Проверка синтаксиса наверняка выполняется до того, как что-то создается (контексты, объекты и проч.), не так ли?

Естественно, и, в случае данной функции (на уровне Program), это будет FD.

Все-таки, дело тут не в элегантности.

Здесь нет однозначного ответа, лишь точки зрения и рассуждения

Как так? Это ведь про тот самый стандарт, о котором повествует данная статья (“ECMA-262-3″ есть, как минимум, в названии).

Что не мешает мне иметь собственное мнение и корректировать стандарт, если потребуется (не важно на каком уровне — в виде ли лишь высказанного мнения в какой-то статье или proposal’а в TC-39).

А вообще, говоря в этой статье про то, что SpiderMonkey IMO прав, я имел в виду, что мне больше симпатизирует именно их реализация расширения, чем другие (где функция убегает наружу из if-блока).

Вероятно потому, что распарсил функцию как FD, которая создается при входе в контекст.

Проверка синтаксиса наверняка выполняется до того, как что-то создается (контексты, объекты и проч.), не так ли?

Если очень интересно, я предлагаю посмотреть грамматику

Верно. Изучив грамматику, можно избежать вопроса, вроде: “почему это, вызов с параметрами не выдает синтаксической ошибки, а без параметров — имеем SynaxError“?

Я понял, поэтому и сказал, что “затраты” разные бывают и посмотрел на это с другой стороны (и отметил Ваши “затраты”).

Зачем вычислять лишнее (булево или что-то еще ненужное)? Все-таки, дело тут не в элегантности.

А какая разница?

Как так? Это ведь про тот самый стандарт, о котором повествует данная статья (“ECMA-262-3″ есть, как минимум, в названии).

Но самое интересно, что в ES6 их хотят имплементировать

However, this plan may not work if ES5 implementations pollute strict mode…

Вот интерпретатор понимает, что тут нет оператора вызова. Почему?

Вероятно потому, что распарсил функцию как FD, которая создается при входе в контекст. Это не CallExpression, за которым следует Arguments, которые и были бы “вызовом”. Если очень интересно, я предлагаю посмотреть грамматику; но по мне — “мануальный парсинг” — утомительно …хоть и полезно.

Я про “затраты” на выполнение (полагаясь на алгоритмы, изложеные в спецификации).

Я понял, поэтому и сказал, что “затраты” разные бывают и посмотрел на это с другой стороны (и отметил Ваши “затраты”).

это из последней версии стандарта

А какая разница? У меня раньше тоже было идеализированное восприятие стандарта. Когда же я сам поучаствовал в дискуссиях, увидел, что это обычный человеческий процесс, основанный на локальных причинах и согласно ситуации и времени. Сегодня так, завтра — Function Statements уже будут стандартизованы. Кстати, FS “забанены” в рекомендации ES5-strict. Но самое интересно, что в ES6 их хотят имплементировать, а забанены они только для того, чтобы “кто в лес, кто по дрова” не лез, как в ES3. А вот уже когда ES6 их стандартизует, тогда уже, пожалуйста, имплементируйте.

тут же столкнемся с вопросом — “почему это, вызов с параметрами не выдает синтаксической ошибки, а без параметров — имеем SynaxError“?

Попробую иначе. Вот интерпретатор понимает, что тут нет оператора вызова. Почему?

В случае с ! мы, например, экономим один символ в отличие от ().

Я про “затраты” на выполнение (полагаясь на алгоритмы, изложеные в спецификации).

Так что “признано”-”непризнано” это лишь временные навешиваемые “лэйблы” конкретных людей

NOTE Several widely used implementations of ECMAScript are known to support the use of FunctionDeclaration as a Statement. However there are significant and irreconcilable variations among the implementations in the semantics applied to such FunctionDeclarations.
– это из последней версии стандарта…

А почему именно круглые скобки интерпретируются оператором группировки, а не оператором вызова?

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

function foo(x) {
  console.log(x);
}(1); // "вызываем" с параметром 1

На деле же, это никакой не вызов (и в консоль, соответственно, ничего не выводится), а лишь правильно оформленный оператор группировки, который следует за декларацией функции.

То же самое:

// декларация
function foo(x) {
  console.log(x);
}

(1); // группировка 1

foo(1); // вызов

Может, это менее “затратный” способ, а элегантность тут не при чем?

Может и так, но я бы не стал исключать элегантность Поскольку “затратность” тоже разная. В случае с ! мы, например, экономим один символ в отличие от (). В случае же со скобками, да, интерпретация возможно будет быстрее.

Нет, не правильно. Доп. возможности и “баловство” с семантикой языка – не одно и то же. Короче, признано существенным противоречием.

FS вернутся в ES.next, и именно в виде, в котором сейчас присутствуют в SpiderMonkey. Так что “признано”-”непризнано” это лишь временные навешиваемые “лэйблы” конкретных людей

Обратите внимание, в данном случае — это именно оператор группировки, который следует за декларацией функции, а не скобки вызова функции!

А почему именно круглые скобки интерпретируются оператором группировки, а не оператором вызова?

Однако скобки являются в данном случае наиболее распространенным и элегантным способом.

Может, это менее “затратный” способ, а элегантность тут не при чем?

Моё мнение, что SpiderMonkey поступает в данном случае правильно, выделяя негласный средний вид функции — (FE + FD).

Нет, не правильно. Доп. возможности и “баловство” с семантикой языка – не одно и то же. Короче, признано существенным противоречием.

.apply и .call

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