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

B>Так понятно. Инструкции также могут обладать всеми этими качествами. Не вижу противоречия.
Я не вижу каким образом инструкции могут обладать этими качествами. Поясните жизненный цикл этих ваших "объектов-инструкций": что является их состоянием, какие сообщения они обрабатывают, какие сообщения посылают другим объектам.

B>>>Компилятор работает на основе синтаксиса. О каком наборе инструкций идет речь?
S>>В общем-то, о любом — и о наборе входных инструкций (или любых других элементов языка), и о наборе выходных инструкций.
B>Входные это о целевой машине идет речь?
Входные — это то, что пишет пользователь.
B>А выходные это результат работы компилятора?
Да.
И с чем не соглаcие? С тем что компилятор работает на основе синтаксиса?
С тем, что входные инструкции в виде объектов зачем-то нужны после того, как отработает компилятор.

B>И что мешает набор инструкций считать объектами?
Отсутствие у них состояния и поведения.
B>А зачем все уничтожать? Кое-что пусть и остается. Как документ.
Документ не имеет никакого отношения к объектам-инструкциям. Рассмотрите документирование кода на примере javadoc. Вы знакомы с этим явлением?

B>Не нужно. Только если их нет где-то, не означает что их нет нигде. У меня есть.
А у вас уже есть целевая машина?

B>Ну, и я так понимаю. Видимо одинаковые книжки читали. Могу еще пример преобразования выражений привести. Вот только ироническое "наивно" не принимаю. Да предлагаю, и отнюдь не наивно. Хотя спорно.
Ну мне описанное кажется немножко наивным. Возможно, это у меня как раз опыта в языкостроении не хватает.

B>Зачем нам i в целевой программе?
B>А для формирования сообщения в случае необходимости в терминах исходника. И для сопровождения, для документирования.
Непонятно. Для сопровождения и документирования достаточно сопровождать и документировать исходник. См. опять же javadoc и XML comments в C#.
Формирование соощения в терминах исходника — крайне редкая необходимость. Кроме того, потребности по формированию этого сообщения совсем другие, чем потребности исполняющей среды по реализации семантики вашей программы.
Приведу такой пример из реального мира: вот у нас бывают исключения в .Net. В исключении для удобста отладки и формирования сообщений приклеен стек вызовов. Сам по себе стек вполне себе объектно-ориентирован (хотя объекты, из которых он состоит, immutable, и общему определению объекта не очень удовлетворяют). Но это не означает, что к исключению приклеивают тот самый стек, который используется внутри исполняющей машины. Никто не создаёт объект StackFrame при каждом вызове подпрограммы. StackTrace собирается из доступной информации только в момент выброса исключения. А для исполнения используется обычный стек x86.
Это сделано не потому, что разработчики CLR не смогли применить передовые концепции, а потому, что они были бы слишком дорогими — производительность была бы ниже всякой критики.


S>>Там связь между "объектами, созданными компилятором" и текстом программы весьма непрямая. Давайте попробуем раскрыть тему и пояснить мне, где здесь сложности документирования и сопровождения? Очень редкий C#-программист может сопоставить текст hello world и инструкции x86, в которые он превращается после работы компилятора и jit. Но никто и никогда не занимается документированием программы в терминах "целевого кода".
B>И напрасно не занимались. Только не в терминах целевого кода, а в терминах исходника.
Я уже писал про javadoc и XML comments?

S>>Ну попробуйте оспорить, раз оно спорное. Вы вообще роль языков программирования в современной индустрии ПО как себе представляете?

B>Ну, на уровне современной индустрии ПО, я, конечно, не смогу ответить. Язык он для человека что б писать, и для компилятора что б он тоже чего-то в нем понимал. Было б странно если б языки только для человека, а каким боком он тогда нужен если его компилятор не понимает?
Я имею в виду, что язык нужно проектировать так, чтобы было удобно человеку. Удобство компилятора — вещь вторичная.
Поэтому преимущества типа "а тут у нас упрощается лексический анализ" являются мнимыми.

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

B>Между вашим представлением, и тем что я предлагаю. Здесь, действительно, разница есть. Возможно терминологическая. Но большая. Потому если продолжать это будет очень длинно. Если пожелаете, то продолжу.
Вы постарайтесь сосредоточиться и отвечать на вопросы. Ваше описание языка совершенно нетрадиционно.
Вы не хотите описать задачи, которые хотите решить вашим языком. Не хотите показать преимущества языка для его пользователей по сравнению с другими языками.