Вышла Lua 5.2

Вот ты, к примеру, утверждал, будто в венде для ядра используются плюсовые исключения... :3

Пруфлинк или GTFO.

Так что разработчики ЯП сознательно отказываются от исключений стиля try-catch-finally.

Не «разработчики», а малахольный нытик Пайк; и даже у него в Go есть finally в неявном виде (defer).

«классическое» исключение тем более завершает не скоп вообще, а конкретно скоп try ... catch

Это где такие странные исключения? Обычно завершается стопицот вложенных областей, пока не дойдет до области с try-catch.

Да, тут я тоже ошибся. Ты этого не утверждал. Я не верно понял вот эту фразу:

Еще раз - ты ищешь Си++-конструкции.

из Вышла Lua 5.2 (комментарий)

python, как любой приличный язык, имеет exceptions и не имеет goto.

Да, ну? Правда, что ле? Ггг.

Это где такие странные исключения? Обычно завершается стопицот вложенных областей, пока не дойдет до области с try-catch.

об том и речь, что завершается не текущий скоп типа for или if, а все скопы, вплоть до программы, если не будет явно заданного try/catch .

«классическое» исключение тем более завершает не скоп вообще, а конкретно скоп try ... catch

Но от этого ваше утверждение, что error() приводит к завершению «не программы, а скопа», не становится более правильным :)

Разница только в том, что мы хорошо себе представляем, что такое pcall и понятия не имеем, что такое try...catch.

Э, нет. Если вы хорошо себе представляете, что такое pcall и понятия не имеете, что такое try...catch, - это, как говорится, ваши проблемы :) Для программиста и то и другое работает согласно спецификации языка.

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

Не совсем так. Снаружи всегда передаются значения, а не переменные. А переменные (параметры функции) всегда определяются «внутри» - за пределами функции (скопа) их не видно. Таким образом, для передачи данных в скоп, переменные должны быть определены всегда. Только в твоём случае они определены как аргументы функции, а в моём - в виде явно объявленных переменных. Семантически нет никакой разницы между:

-- file1.lua ----------
function f(arg)
  ...
  if arg == 123 then
    ...
  end
end
  ...
-- file2.lua ----------

  require "file1"

  pcall(f, 123)

-- file1.lua ----------
  try
    if arg == 123 then
      ...
    end
  catch
    ...
  end
  ...

-- file2.lua ----------

  local arg = 123

  require "file1"

Именно гибкость стандартного lua позволяет проводить такие фокусы.

Я думаю, такие фокусы позволяет проводить не гибкость стандартного lua, а доступность его исходников :)

В языке появился оператор goto

Свой язык сделать что ли...

Семантически это тоже разные вещи.

Семантически нет никакой разницы между:

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

python, как любой приличный язык, имеет exceptions и не имеет goto.

Да, ну? Правда, что ле? Ггг.

ты не поверишь, но это - чистая правда. а ты правда не знал? хотя, чего еще ожидать от тех, кто использует «ггг»?

Какой недалекий анонимус пошел. Намеки совсем не понимает.

Не болтай ерундой. ntdll.dll - это winapi интерфейс для вызовов из ntoskrnl.exe, с отображением 1:1, а никакое не подобие libc.

ntdll.dll вообще никакого отношения к Win32 API не имеет, недоумок. Это именно самый нижний слой юзерленда, как и libc в этих ваших юниксах.

ntdll.dll вообще никакого отношения к Win32 API не имеет

Без ntdll.dll в адресном пространстве не будет работать ни один winapi процесс, идиот. А «winapi интерфейс» в данном контектсе означает соглашения о вызовах и формат двоичного файла, дебил.

Это именно самый нижний слой юзерленда, как и libc в этих ваших юниксах.

Иди читай, что такое стандартная библиотека C, тупица. Как выглядит её реализация в венде я уже сказал выше.

python, как любой приличный язык, имеет exceptions и не имеет goto.

Это у которого коробка уже под 50 мегабайт, помойка вместо стандартной библиотеки, каша из парадигм и нотаций всех мастей вместо синтаксиса и скорость чуть медленней, чем у своего названия?

Без ntdll.dll в адресном пространстве не будет работать ни один winapi процесс, идиот. А «winapi интерфейс» в данном контектсе означает соглашения о вызовах и формат двоичного файла, дебил.

Не лепи гнилые отмазки. Лажанулся - признай. Я пойму и прощу. И да, расскажи, как будет работать процесс в линаксе без libc, и заодно дай определение «winapi процесса». Кроме того, открой грамматику русского языка и узнай наконец, что атрибутивных существительных в русском языке нет. Это я тебе про «winapi процесс», если ты не догадался.

Иди читай, что такое стандартная библиотека C, тупица. Как выглядит её реализация в венде я уже сказал выше.

Назови мне, умничка, самый нижний слой юзерленда в юниксах.

В языке появился оператор goto

Ну наконец-то язык перестал быть студенческой поделкой и вступил в пору зрелости.

Это у которого коробка уже под 50 мегабайт, помойка вместо стандартной библиотеки, каша из парадигм и нотаций всех мастей вместо синтаксиса и скорость чуть медленней, чем у своего названия?

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

расскажи, как будет работать процесс в линаксе без libc

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

Это я тебе про «winapi процесс»

Ну ты же не думаешь, что я ради тебя буду расписывать «образ процесса ... win32 подсистемы» и т.д. Сам должен сообразить, о чём речь, не маленький.

Назови мне, умничка, самый нижний слой юзерленда в юниксах.

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

Как напишешь, так и будет.

Приведи пример исходника юзерлендовской программы на C, которая не юзает libc.

За подробностями в гугл, ищущий знаний да обрящет.

Я тебя тоже могу послать, регистрант, но не буду.

Ну ты же не думаешь, что я ради тебя буду расписывать «образ процесса ... win32 подсистемы» и т.д. Сам должен сообразить, о чём речь, не маленький.

win32 подсистемы

Вижу, ты так и не понял свою ошибку, несчастный.

Дурачок, в юниксах нет нижнего слоя юзерленда.

Ога, все программы дергают за коллгейты. Оказывается, ты и юниксов не знаешь.

За загрузку образа в память и пуск программы на счет отвечает само ядро. Даже шебанг парситься ядром, ага.

Ичо?

Еще наверняка будет пара-тройка минорных релизов ветки 5.2, в которых дочистят баги. А потом, может, и luajit подтянется и тогда можно будет тягаться по скорости с си и явой 8-). А пока lua 5.1 + luajit вполне устраивает.

я не понял, что ты имеешь сказать

Это не удивительно. Любому человеку с мозгом очевидно, что пестон - эклектичное гуано. Например, объясни, какого органа строка, которая типа объект, не имеет атрибута длины, и длину эту надо узнавать через процедурную нотацию?

А еще есть llvm-lua...

Но от этого ваше утверждение, что error() приводит к завершению «не программы, а скопа», не становится более правильным :)

ну как сказать. Они или оба допустимы, или оба неправильны. Я только хотел сказать, что нет какой-то особой разницы. Один вариант чуть гибче, а другой чуть сахаристей на вид, но в целом одно и тоже.

Э, нет. Если вы хорошо себе представляете, что такое pcall и понятия не имеете, что такое try...catch, - это, как говорится, ваши проблемы :) Для программиста и то и другое работает согласно спецификации языка.

Тоже вроде не поспоришь. В идеале все, что в языке навернуто всегда работает по спецификации. Проблема в том, что, во первых, не всегда спецификации достаточно полно описывают поведение и во вторых, не всегда компиляторы и инфраструктура языка в целом следуют им. Поэтому в одном случае нам достаточно знать спецификацию, поведение и баги механизма функций в языке. И знать нам их по любому надо, ибо как писать программы без функций? А в другом случае нам надо еще _дополнительно_ знать спецификацию, полноту реализации и баги механизма исключений. На свете есть много программ, написанных без использования исключений и, стало быть, это редкий в использовании механизм не проходит столь изощренного тестирования, как общеупоребительный механизм функций.

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

Это не про луа. В луа вообще можно передать в функцию другую функцию, которая определит, все что надо.

А переменные (параметры функции) всегда определяются «внутри» - за пределами функции (скопа) их не видно.

это не про луа.

[avl@localhost tmp]$ lua test.lua

inscope=1

function test1 () print («inscope=» .. inscope) end

function test2 () outscope=2 end

test1()

test2()

print («outscope=» .. outscope)

[avl@localhost tmp]$ lua test.lua

inscope=1

outscope=2

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

Разница в удобстве. Здесь луа более удобен и все.

Я думаю, такие фокусы позволяет проводить не гибкость стандартного lua, а доступность его исходников :)

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

Например, объясни, какого органа строка, которая типа объект, не имеет атрибута длины, и длину эту надо узнавать через процедурную нотацию?

Это таки лучше, чем фееричный зоопарк с size/length/count и т.д., что еще может взбрести в голову упоротым ООП.

man Threaded code

Это таки лучше, чем фееричный зоопарк с size/length/count и т.д., что еще может взбрести в голову упоротым ООП.

Это тоже клинический случай, да. ООП тут ни при чем. Все должно быть единообразно: и грамматика и лексика. Короче, оба хуже.

Например, объясни, какого органа строка, которая типа объект, не имеет атрибута длины, и длину эту надо узнавать через процедурную нотацию?

Сразу, как только ты объяснишь, почему длинна объекта и не объекта должна добываться разными путями?

Другими словами, если строка - объект, то x = строка.len, а если буфер с теми же байтами, это не объект, то y = len(буфер)?

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

А тебе не нужно помнить, когда парадигмы полноценные. Хочешь, пишешь в объектной нотации, хочешь - в процедурной. Нахрена помойку разводить? Это риторический вопрос, ибо ежу понятно, что язык лепили кое-как на коленке.

P. S. Подучи орфографию, позорище же!

Все должно быть единообразно: и грамматика и лексика

как в лиспе - скобочки, скобочки, скобочи...

А тебе не нужно помнить, когда парадигмы полноценные.

А тогда получается жаба головного мозга. Простые типы обертывать в объекты бывает накладно.

В си - да, гоуту. Либо return(!).

можно обойтись переменными и несколькими ифами, тока мусорнее в коде будет.

В плюсах можно и исключение кинуть :)

Исключение Страуструп не рекомендует кидать часто, так как накладно получится.

Я люблю исключения и не воспринимаю их как только способ уведомить об *исключительной* ситуации

Исключения по тому и назваются исключениями, что они отличаются от обычного режима работы функции/процедуры. Исключения ИМХО стоит делать только в вызываемых библиотеках. Во всех остальных случаях проще отследить работу коду менее экстремальными методами и ловить исключения из вызываемых библиотек.

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