Здравствуйте, Sinclair, Вы писали:
S>То есть вы хотите сказать, что в вашем случае программа сразу существует не в текстовом виде, а в виде AST?
И в текстовом, и лексемы, и объекты созданые синтаксисом.
S>Подход интересный, хотя и не новый. Его основная проблема — в том, что в нём не может существовать некорректная программа. На первый взгляд это здорово, но на практике оказывается помехой. Привычные методики типа Copy-Paste здесь не работают.
Почему не работают? Все как обычно, и даже можно перетаскивать объекты с панели инструментов. В нашей терминологии это классы, а дроп-даун создаются объекты.
S>Расскажите, как вы собираетесь бороться с отсутствием отдельной фазы компиляции, которая запускается вручную.
Почему отсутствует фаза компиляции? И фаза применения сценариев есть (она же интерпретация), и компиляция, и выполнение.
B>>3. Синтаксический анализ создает из последовательности объектов-лексем и объектов-знаков новые объекты! Так как синтаксис у меня простой сначала имя класса ,а затем имя создаваемого объекта (далее в скобках идет присвоение значений свойств объекту и определение вложеных объектов) то выглядит это примерно так.
B>>B>>Form Fm {Size=120;50 Label Lb {Size=20;30 Text="Конечно"}}
B>>For I=0 To N { J+=1 Z=X*Y}
B>>
B>>Из первой строки синтаксический анализатор создаст форму с вложеной меткой и текстом "Конечно".
B>>Вторая строка создаст объект-инструкцию класса For, с вложенными операторами J+=1 Z=X*Y
S>Это всё понятно. Непонятно, зачем вы создаёте эту объект-инструкцию. Точнее, зачем вы на этом концентрируетесь.
Для того что б был понятен подход.
S>В обычном жизненном цикле программы все эти объекты эфемерны — они существуют во время работы компилятора. Как только компилятор сгенерировал целевой код, никакие объекты-инструкции не нужны.
А вот и не правильно. Во-первых почему бы инструкциям не иметь единый формат как и всем объектам? Никаких ограничений я не вижу. А во-вторых есть еще этап сопровождения и анализа уже готовой программы. Т.е. уже готовую программу можно рассматривать как документ и проверять ее логику или верификацию. Есть много чего можно сделать с готовой программой.
B>>Совершенно верно изумление. Мы создаем оператор For в динамической области. Давай только не будем сейчас обсуждать зачем это нужно.
S>Как это? Вопрос "зачем это нужно" здесь главный.
Если не нужно, то не делай. Но, просто есть возможность программой создавать программу.
B>>Теперь, надеюсь, понятно, что такая многоуровневость позволяет иметь абсолютно всю информацию как при выполнении так и при редактировании, и позволяет создавать как программы, так и документы.
S>Осталось понять, зачем нужна "абсолютно вся" информация. В практических подходах ограничиваются той информацией, которая нужна. Ну вот например нужно нам определять, в каком месте исходной программы случился breakpoint при отладке. Совершенно не обязательно при выполнении хранить где-то копию этих строчек и заниматься интерпретацией. Достаточно иметь файл символов, которые позволяют отобразить адреса в имена и ссылки.
Эти имена и есть лексемы. Так что ничего плохого в этом нет. Много информации не бывает. Зато сообщение можно сформулировать в терминах предметной области. Что несколько лучше чем в ноликах и единичках.
Хотя есть возможность сохранить только объекты-результат трансляции или только лексемы. Ведь объекты-инструкции хранят в себе все имена, классы и прочее. держать еще текст нет никакого смысла.
