Здравствуйте, Mamut, Вы писали:

a>> ECMA-262, 3я редакция, раздел 12.2:
a>>

a>> Блок не определяет новой области выполнения. Только Программа и ОбъявлениеФункции создают новую область видимости.

M>Но тогда описаное поведение жутко неявное. Получается, что локальность переменной определена только в конце функции, да еще после return'а...

Оно явно описано в разделе 10.1.3 той же спецификации:

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

При входе в контекст выполнения свойства привязываются к объекту переменных в следующем порядке:

[...]

* Для каждого ОбъявленияПеременной или ОбъявленияПеременнойБезIn в исходном коде, создать свойство в объекте переменных с именем Идентификатора, указанного в ОбъявленииПеременной или ОбъявленииПеременнойБезIn, значение которого равно undefined и атрибуты которого определяются типом кода. Если в объекте переменных уже существует свойство с именем объявленной переменной, значение свойства и его атрибуты не изменяются. Семантически этот шаг должен следовать за созданием свойств для СпискаФормальныхАргументов и ОбъявленийФункций.

Таким образом все объявления переменных учитываются при входе в контекст, а лишь затем начинается выполнение кода.

Здравствуйте, anonymous, Вы писали:

A>Оно явно описано в разделе 10.1.3 той же спецификации:

A>Для каждого контекста выполнения имеется связанный с ним объект переменных. Переменные и функции, определённые в исходном тексте, добавляются в качестве свойств объекта переменных.

Это ты сам переводишь или где-то есть в электронном виде перевод?

Здравствуйте, _FRED_, Вы писали:

A>>Оно явно описано в разделе 10.1.3 той же спецификации:
_FR>

A>>Для каждого контекста выполнения имеется связанный с ним объект переменных. Переменные и функции, определённые в исходном тексте, добавляются в качестве свойств объекта переменных.

_FR>Это ты сам переводишь или где-то есть в электронном виде перевод?

Ага!

a> Таким образом все объявления переменных учитываются при входе в контекст, а лишь затем начинается выполнение кода.

Жесть, однако 0_о

Здравствуйте, Mamut, Вы писали:

a>> Таким образом все объявления переменных учитываются при входе в контекст, а лишь затем начинается выполнение кода.
M>Жесть, однако 0_о

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

Мне вот интересно, почему так было сделано: что контексты не порождаются блоками кода. Нигде не видел объяснения.

Здравствуйте, c-smile, Вы писали:

Еще одна пеночка от Doug Crockford.

Это вот:

function foo()
{
  return 
  {
    ok:true
  };
}

вернет undefined.

А это:

function foo()
{
  return { 
    ok:true 
  };
}

вернет объект { ok:true }

Как-то ECMA как standards body доверия не вызывает...

Какой-то идиот придумал этот semicolon injection а ECMA это пропустил.

Здравствуйте, anonymous, Вы писали:

A>Здравствуйте, z00n, Вы писали:

Z>>JS печально известен своим идиотским правилом, что у него один scope на тело функции.

A>Почему идиотским?

Оно идиотское в контексте остального языка.
Язык обманчиво похож на С, а ведет себя как Pascal, при этом в паскале нельзя объявлять переменные где попало, а в JS можно. И еще то, что порядок объявления не важен.
С другой стороны с 75 года известен язык, похожий на JS (Scheme: первоклассные фукции etc.) в котором тоже единственным способом объявить блок является функция, но там ввели (by design) макрос let который позволяет прозрачно писать:

(let ((x 2)(y 3))
  (* x y))
; вместо
((lambda (x y) (* x y)) 2 3)

Для более-менее сложных программ это бесконечный источник уродств и граблей.

//allow a node to propagate only once
    c.once_e = function (maybeKeyNode, event) 
    {
        if (!(event instanceof e.Node)) { throw 'once_e: expected Event as second arg'; } //SAFETY

        var done = false;
        return e.createNode(
            maybeKeyNode, 
            [event],
            (function () {
                done = false;
                return function (send, pulse) {
                        if (!done) {done = true; send(pulse); }
                }; })());
    };

И наконец в JS 1.7 ввели let — почему было сразу так не сделать, а не ждать пока он станет де-факто стандартом веба?
https://developer.mozilla.org/En/New_in_JavaScript_1.7
http://wiki.ecmascript.org/doku.php?id=discussion:block_expressions

Dave Herman (ex разработчик JS4)
Exercise:
1. Release a new version of a popular, commercial web browser.
2. In the new release, change the semantics of the web in some fundamental way--say, variable binding.
3. Break every scripted web page in existence, including Yahoo, eBay, GMail, you name it.
4. Try to convince users to upgrade to your new release.

Alternatively, try to convince major web application vendors to support two different semantics for your scripting language concurrently so their applications work in all popular releases of your browser. (Keep in mind it takes years before "legacy" browsers are no longer used on most desktops.)

Возвращаясь к исходному примеру: зачем вообще было разрешать писать стейтменты после return? В Lua, например, это была бы просто синтаксическая ошибка, и пришлось бы вводить отдельный блок для return:

function test()
  local somevar = 1;
  do 
    return somevar;
  end
  if false then local somevar; end
end

Здравствуйте, c-smile, Вы писали:

CS>(Не уверен за правильность нотации, извиняюсь, но мысль должна быть понятна)
CS>Т.е. есть ли у Python block scopes? Или тоже все внавал лежит?

Нет. Наличие global где угодно делает имя глобальным еще до выполнения функции:

v = 100

def test():
    print(v) # 100
    v = 1
    print(v) # 1
    return v
    global v

print(test()) # 1
print(v) # 1

Но только для этой функции (не для вложенных например)

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, c-smile, Вы писали:

CS>>(Не уверен за правильность нотации, извиняюсь, но мысль должна быть понятна)
CS>>Т.е. есть ли у Python block scopes? Или тоже все внавал лежит?

Кё>Нет. Наличие global где угодно делает имя глобальным еще до выполнения функции:

"Нет" что? Нет block scopes?

Кё>

Кё>v = 100

Кё>def test():
Кё>    print(v) # 100
Кё>    v = 1
Кё>    print(v) # 1
Кё>    return v
Кё>    global v

Кё>print(test()) # 1
Кё>print(v) # 1
Кё>

Кё>Но только для этой функции (не для вложенных например)

Мммм.... я прав что это та же хрень что и в JS?
Т.е. стоит где-то поглубже закопать 'global v' и что привет локальной дефиниции?

Здравствуйте, c-smile, Вы писали:

CS>Еще одна пеночка от Doug Crockford.

И это тоже описано в стандарте в разделе 7.9, касающемся автоматической расстановки точек с запятой:

[...]

Итоговые практические советы программистам на ECMAScript таковы:

* Постфиксный оператор ++ или -- должен появляться на той же строке, что и его операнд.
* Выражение в инструкциях return или throw должно начинаться на той же строке, что и токен return или throw.
* Метка в инструкцииях break или continue должна находиться на той же строке, что и токен break или continue.

Здравствуйте, z00n, Вы писали:

Z>>>JS печально известен своим идиотским правилом, что у него один scope на тело функции.
A>>Почему идиотским?
Z>Оно идиотское в контексте остального языка.
Z>Язык обманчиво похож на С, а ведет себя как Pascal, при этом в паскале нельзя объявлять переменные где попало, а в JS можно. И еще то, что порядок объявления не важен.

Ну, это ни разу не объяснение. Существует огромное количество Си-подобных языков, с совершенно разным поведением, и вдруг они все становятся идиотскими.

Z>Возвращаясь к исходному примеру: зачем вообще было разрешать писать стейтменты после return?

Известно для чего, чтоб удобнее было стрелять в ногу. А если серьёзно, то после return можно, к примеру, наобъявлять локальных функций.

Здравствуйте, c-smile, Вы писали:

CS>Мммм.... я прав что это та же хрень что и в JS?
CS>Т.е. стоит где-то поглубже закопать 'global v' и что привет локальной дефиниции?

Да. Поэтому и варнинг выдается.

Здравствуйте, anonymous, Вы писали:
Z>>Язык обманчиво похож на С, а ведет себя как Pascal, при этом в паскале нельзя объявлять переменные где попало, а в JS можно. И еще то, что порядок объявления не важен.

A>Ну, это ни разу не объяснение. Существует огромное количество Си-подобных языков, с совершенно разным поведением, и вдруг они все становятся идиотскими.

В области языкостроения есть ряд вопросов, по которым достигнут консенсус. Блочные области видимости — это один из таких вопросов.

Здравствуйте, palm mute, Вы писали:

PM>В области языкостроения есть ряд вопросов, по которым достигнут консенсус. Блочные области видимости — это один из таких вопросов.
Естественно, такой список нигде не высечен в камне, но обсуждение на LtU, по-моему, закрывает эту тему.

Здравствуйте, c-smile, Вы писали:

Кё>>def test():
Кё>> print(v) # 100
Кё>> v = 1
Кё>> print(v) # 1
Кё>> return v
Кё>> global v

Кё>>print(test()) # 1
Кё>>print(v) # 1
Кё>>[/python]

Кё>>Но только для этой функции (не для вложенных например)

CS>Мммм.... я прав что это та же хрень что и в JS?
CS>Т.е. стоит где-то поглубже закопать 'global v' и что привет локальной дефиниции?

Компилятор действительно не различит, но проверять только компилятором для Питона — хуже чем моветон, это профнепригодность:) А вот pychecker такие вещи подробно комментирует:

$ pychecker 2.py
Processing module 2 (2.py)...
2.py:8: SyntaxWarning: name 'v' is assigned to before global declaration
global v
2.py:8: SyntaxWarning: name 'v' is assigned to before global declaration
global v

Warnings...

None

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

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, c-smile, Вы писали:

CS>>Мммм.... я прав что это та же хрень что и в JS?
CS>>Т.е. стоит где-то поглубже закопать 'global v' и что привет локальной дефиниции?

Кё>Да. Поэтому и варнинг выдается.

Ну т.е. та же проблема что и в JS.
В принципе для Python это не так критично ибо у него нет явно выраженных синтаксически scopes.
Но все равно, осадок остается. Но это субъективно конечно.
Вообще JS и Python и архитектурно (структура VM и runtime) и по идее своей очень близкие языки. Нотация разная — да, а так практически идентичны.

Здравствуйте, c-smile, Вы писали:

CS>(попробуйте предсказать вывод тех alert()ов, ответ для ленивых в конце сообщения)

Тут кстати нельзя не вспомнить Io, где можно просто вылезать куда хочешь — в локальный scope вызывающего, в global (Lobby), и т.п. без синтаксических заморочек:

x := 100
y := 200
z := 300

main := method(

    x := 10
    y := 20
    z := 30

    test := method(
        x := 1
        Lobby y := 2
        call sender z := 3
        x
    )

    writeln("local: test=", test, " x=", x, " y=", y, " z=", z)
)

main
writeln("global: x=", x, " y=", y, " z=", z)

local: test=1 x=10 y=20 z=3
global: x=100 y=2 z=300

Здравствуйте, palm mute, Вы писали:

PM>>В области языкостроения есть ряд вопросов, по которым достигнут консенсус. Блочные области видимости — это один из таких вопросов.
PM>Естественно, такой список нигде не высечен в камне, но обсуждение на LtU, по-моему, закрывает эту тему.

О да, конечно, разве ж можно спорить с аргументацией типа «я к этому не привык». Придётся и вправду закрыть эту тему, раз нет более внятных аргументов.

Здравствуйте, anonymous, Вы писали:

A>Здравствуйте, c-smile, Вы писали:

CS>>Еще одна пеночка от Doug Crockford.

A>И это тоже описано в стандарте в разделе 7.9, касающемся автоматической расстановки точек с запятой:

Это хорошо что оно описано. Плохо (до полной ужасности) что оно вообще такое есть.

С grammar разрабатывалась прнципиально не чувствительной к CR-LF и их комбинациям.

Предполагается что это свойство наследуется всеми языками использующими её.
И это действительно так за единственным исключением — ECMAScript.
Абсолютно не понятно почему оно так собственно. Ради чего?

A>Итоговые практические советы программистам на ECMAScript таковы:

A>

A>[...]
A>* Постфиксный оператор ++ или -- должен появляться на той же строке, что и его операнд.
A>* Выражение в инструкциях return или throw должно начинаться на той же строке, что и токен return или throw.
A>* Метка в инструкцииях break или continue должна находиться на той же строке, что и токен break или continue.

Угу, вот так сказать more of those:

Когда Сатурн в Весах то код на JavaScript лучше не писать вообще. Переключитесь на нечто более предсказауемое, например CSS дизайн.

Здравствуйте, c-smile, Вы писали:

A>>И это тоже описано в стандарте в разделе 7.9, касающемся автоматической расстановки точек с запятой:
CS>Это хорошо что оно описано. Плохо (до полной ужасности) что оно вообще такое есть.
CS>С grammar разрабатывалась прнципиально не чувствительной к CR-LF и их комбинациям.
CS>Предполагается что это свойство наследуется всеми языками использующими её.
CS>И это действительно так за единственным исключением — ECMAScript.
CS>Абсолютно не понятно почему оно так собственно. Ради чего?

Тут в «Веб программировании» постоянно приходится указывать пользователям, что JavaScript — не Java, похоже, пора указать и, что JavaScript — не C. JavaScript не использует грамматику Си, он использует грамматику, похожую внешне на грамматику Си, но другую. В нём пробельные символы напрямую влияют на семантику, это такая особенность, призванная превратить неверный код в верный.

Например будет прекрасно работать код:

if (something) alert('something')
else alert('nothing')

потому что он эквивалентен

if (something) alert('something');
else alert('nothing');

CS>Угу, вот так сказать more of those:
CS>

CS>Когда Сатурн в Весах то код на JavaScript лучше не писать вообще. Переключитесь на нечто более предсказауемое, например CSS дизайн.

Нет, я не понимаю, что в JavaScript непредсказуемого (не необычного, а непредсказуемого) после прочтения спецификации?