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

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

XC>>>Это какая-то попытка запихать инструкции (операторы языка) в парадигму ООП?
B>>Да. Только почему "запихать"? Так оно и есть..Объект-инструкция..
B>> А почему бы и нет?
Раз 5 перечитал. Не уловил логику. Извини.
S>А, собственно, зачем? У инструкции никакого поведения нет. Поведение есть у компилятора, который на основе набора инструкций должен породить программу для целевой машины.
И что имеется ввиду под поведением?
Компилятор работает на основе синтаксиса. О каком наборе инструкций идет речь?
А если целевая машина принимает на входе объекты? Логично тогда ожидать что компилятор должен создать объекты? Не надо зацикливаться на том, что целевая машина это воспринимает только коды процессора.
И, наконец, не понял что именно следует из вашего замечания.

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


S>Задача "объекта-инструкции" сводится к тому, чтобы хранить данные, необходимые для компилятора. И это мало кому интересно — потому, что код компилируется один раз, а исполняется — миллионы раз.
S>Ну, то есть устройство компилятора само по себе конечно же интересное дело — вон как народ по соседству бурлит насчёт всех этих GLR парсеров и прочего. Но проектировать из этого язык... Язык нужен для человека, а не для компилятора.
Спорное утверждение.
К тому же в компиляции процесс лексического и синтаксического разбора — далеко не самая интересная задача. Дальше-то вы что будете делать? Каким образом вы собираетесь порождать целевой код?
По-моему ответил.
Или это будет чистая интерпретация?

И интерпретация и компиляция.
Интерпретация применяется как текстовый процессор. Те же операторы, работающие с теми же объектами, если данные оператора имеют значения на этапе редактирования, то почему бы его не выполнить?
Например, если в тексте 7+5 почему бы не выполнить оператор сложения? Кроме того у меня предусмотрен сценарий в котором можно (а иногда и нужно) определять как структуры данных, так и сами данные. И в тексте программы или текстового документа (в моем редакторе нет разницы) оператор Var определяет типа статические значения, которые можно использовать в качестве данных, тогда следующий оператор выполнится как интерпретатор.

Var Boolean Debug=True
...
..
If F then {Print "a"}
...

А затем поступит в компилятор.. и т.д..
Единственная разница, что у меня все операторы могут выполняться как интерпретаторы.