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

B>И что имеется ввиду под поведением?
Под поведением имеется в виду то, которое из стандартного определения объекта: объект суть сущность, обладающая идентичностью, состоянием, и поведением.
То есть — способность объекта реагировать на посылаемые ему сообщения, возможно изменяя своё состояние.
Пока понятно?

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

B>А если целевая машина принимает на входе объекты? Логично тогда ожидать что компилятор должен создать объекты?
Ну, во-первых, я с такими целевыми машинами не встречался. Они все до единой, по какому-то странному сговору, принимают набор инструкций на некотором языке. Во-вторых, не очень понятно, что значит "создать объекты". Кто, скажем, эти объекты будет уничтожать?
B>Не надо зацикливаться на том, что целевая машина это воспринимает только коды процессора.
Я не зацикливаюсь. Целевой машиной может быть jvm, в которой свой набор инструкций. Или, к примеру, мы можем говорить о компиляции в MSIL — объектно-ориентированный ассемблер. То, что в MSIL никаких объектов по-прежнему нет, объяснять нужно?

B> При этом эта программа зачастую достаточно сильно отличается по структуре от структуры исходной программы.
B>Ну, отличается. Это хорошо или плохо?
Это, в общем случае, хорошо. Потому что позволяет сделать скомпилированную программу эффективнее исходной.
B>По моему плохо. Я бы предпочел что б не отличалось. И это тоже можно сделать, если целевая машина будет моделировать машину Тьюринга с дополнительной адресной лентой, а не исполнять инструкции подряд.
А я бы предпочёл, чтобы скорость света была на пару десятков порядков выше. Шутка.
Поймите, я говорю о том, что если в исходном языке есть конструкция "for i=0 to 10 {...}", то нет никакой гарантии в том, что в выходной программе останется хоть что-то, напоминающее по своей семантике for. В самом простом случае компилятор может развернуть цикл, в сложном — вообще упростить всё вычисление до константы. А вы наивно предлагаете создавать объекты для всего, встреченного компилятором. Зачем нам i в целевой программе?

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

S>>Ну, то есть устройство компилятора само по себе конечно же интересное дело — вон как народ по соседству бурлит насчёт всех этих GLR парсеров и прочего. Но проектировать из этого язык... Язык нужен для человека, а не для компилятора.
B>Спорное утверждение.
Ну попробуйте оспорить, раз оно спорное. Вы вообще роль языков программирования в современной индустрии ПО как себе представляете?

B>По-моему ответил.
По-моему нет.

B>И интерпретация и компиляция.
B>Интерпретация применяется как текстовый процессор. Те же операторы, работающие с теми же объектами, если данные оператора имеют значения на этапе редактирования, то почему бы его не выполнить?
Текстовый процессор бесконечно далёк от интерпретации. Зачем вы его упоминаете? Вот, например, я пользуюсь текстовым процессором Microsoft Word версии 14. Он, конечно, занимается интерпретацией вводимых в него текстов документов — ну, скажем, угадывает, что после точки должно начаться новое предложение и предлагает мне начать дальнейший текст с заглавной буквы. Но это совсем не то, чего мы ожидаем от среды программирования.

B>Например, если в тексте 7+5 почему бы не выполнить оператор сложения? Кроме того у меня предусмотрен сценарий в котором можно (а иногда и нужно) определять как структуры данных, так и сами данные. И в тексте программы или текстового документа (в моем редакторе нет разницы) оператор Var определяет типа статические значения, которые можно использовать в качестве данных, тогда следующий оператор выполнится как интерпретатор.
Не очень понятно, что значит "выполнится как интерпретатор"? У меня закрадывается подозрение, что вы используете стандартные термины каким-то очень нешаблонным способом. В частности, здесь субъект и объект явно перепутаны местами.
Обычно интерпретатор занимается выполнением операторов.
Ну вот, к примеру, интерпретатор читает предложение LET Z = X+Y. Он сразу интерпретирует его как инструкцию завести в виртуальной машине переменную с именем Z и положить в неё результат выполнения оператора + над переменными X и Y. И немедленно выполняет.
Но сам оператор + здесь ничего не делает. Это всего лишь идентификатор, который помогает интерпретатору понять, что нужно делать.

B>А затем поступит в компилятор.. и т.д..
Что именно затем поступит в компилятор? И что именно делает у вас компилятор?
B>Единственная разница, что у меня все операторы могут выполняться как интерпретаторы.
Разница между чем и чем, простите?