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

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

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

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

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

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

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

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

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

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

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

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