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

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

B>>Так понятно. Инструкции также могут обладать всеми этими качествами. Не вижу противоречия.
S>Я не вижу каким образом инструкции могут обладать этими качествами. Поясните жизненный цикл этих ваших "объектов-инструкций": что является их состоянием, какие сообщения они обрабатывают, какие сообщения посылают другим объектам.
Сначала про "жизненный цикл". В общем случае объекты создаются не только динамически. Есть статические объекты. Есть базы данных или текст. Это тоже объекты и хотя это не программа (а у меня нет разницы между программой и документом. Даже форматов нет.). А в программе есть инструкции. Это тоже объекты. Говорить о жизненом цикле таких объектов. Ну, вот сколько существует документ, столько и существуют в нем объекты. Объекты создающиеся динамически это просто объекты к которым применяется оператор (инструкция, объект) Dim или New.
Итак, как у меня создаются объекты? Подчеркиваю У МЕНЯ. Хотя все происходит как обычно, просто я акцентирую на этом внимание потому, что предлагаю именно такой подход.
1. Первый уровень объектов мы создаем клавиатурой. Это, буквы и знаки (в дальнешем просто знаки)и размещаются в документе по общепринятым правилам. В общем случае каждому знаку соответсвует какой-то объект. В частном случае это знаки.

2. Второй уровень объектов возникает при лексическом анализе. Это и лексемы и значения. Лексический анализатор встретив в тексте "10" создает объект класса Integer со значением 10, а встретив 1.Июня.1998г создаст объект класса Date, c соответствующим значением. Ну, и создаются объекты-лексемы, согласно лексического анализа. Так как глубоко в лексику языка мы внедряться не будем, то и примеры лексем я опущу. Но, факт в том, что последовательность объектов-знаков преобразуется в объекты-лексемы. И теперь мы можем смотреть на текст с двух точек зрения. С одной стороны это знаки. Каждый из которых может иметь значения свойств соответсвующих своему классу. Например шрифт, цвет и т.д..
С другой стороны эти знаки составляют лексему. А это объект совсем другого класса и со своими значениями свойств, которые вполне возможно заинтересуют нас процессе отладки, и сто процентов будут использованы в синтаксическом анализе. Такой вот двойственный подход. Но это еще не все. Есть и третий уровень создания объектов.
3. Синтаксический анализ создает из последовательности объектов-лексем и объектов-знаков новые объекты! Так как синтаксис у меня простой сначала имя класса ,а затем имя создаваемого объекта (далее в скобках идет присвоение значений свойств объекту и определение вложеных объектов) то выглядит это примерно так.

Form Fm {Size=120;50 Label Lb {Size=20;30 Text="Конечно"}}
For I=0 To N { J+=1 Z=X*Y}

Из первой строки синтаксический анализатор создаст форму с вложеной меткой и текстом "Конечно".
Вторая строка создаст объект-инструкцию класса For, с вложенными операторами J+=1 Z=X*Y

Это все будет документ, и здесь нет объектов созданных динамически во время выполнения программы. Для создания динамических объектов, необходимо применить к объекту объект-инструкцию класса Dim или New. Вот так

New Form Fm {Size=120;50 Label Lb {Size=20;30 Text="Конечно"}}
New For I=0 To N { J+=1 Z=X*Y}

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

Фух! Перерыв.

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

B>Сначала про "жизненный цикл". В общем случае объекты создаются не только динамически. Есть статические объекты. Есть базы данных или текст. Это тоже объекты и хотя это не программа (а у меня нет разницы между программой и документом. Даже форматов нет.). А в программе есть инструкции. Это тоже объекты. Говорить о жизненом цикле таких объектов. Ну, вот сколько существует документ, столько и существуют в нем объекты. Объекты создающиеся динамически это просто объекты к которым применяется оператор (инструкция, объект) Dim или New.
То есть вы хотите сказать, что в вашем случае программа сразу существует не в текстовом виде, а в виде AST?
Подход интересный, хотя и не новый. Его основная проблема — в том, что в нём не может существовать некорректная программа. На первый взгляд это здорово, но на практике оказывается помехой. Привычные методики типа Copy-Paste здесь не работают.

Расскажите, как вы собираетесь бороться с отсутствием отдельной фазы компиляции, которая запускается вручную.

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
Это всё понятно. Непонятно, зачем вы создаёте эту объект-инструкцию. Точнее, зачем вы на этом концентрируетесь.
В обычном жизненном цикле программы все эти объекты эфемерны — они существуют во время работы компилятора. Как только компилятор сгенерировал целевой код, никакие объекты-инструкции не нужны.

B>Совершенно верно изумление. Мы создаем оператор For в динамической области. Давай только не будем сейчас обсуждать зачем это нужно.
Как это? Вопрос "зачем это нужно" здесь главный.

B>Теперь, надеюсь, понятно, что такая многоуровневость позволяет иметь абсолютно всю информацию как при выполнении так и при редактировании, и позволяет создавать как программы, так и документы.
Осталось понять, зачем нужна "абсолютно вся" информация. В практических подходах ограничиваются той информацией, которая нужна. Ну вот например нужно нам определять, в каком месте исходной программы случился breakpoint при отладке. Совершенно не обязательно при выполнении хранить где-то копию этих строчек и заниматься интерпретацией. Достаточно иметь файл символов, которые позволяют отобразить адреса в имена и ссылки.

Здравствуйте, 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 при отладке. Совершенно не обязательно при выполнении хранить где-то копию этих строчек и заниматься интерпретацией. Достаточно иметь файл символов, которые позволяют отобразить адреса в имена и ссылки.
Эти имена и есть лексемы. Так что ничего плохого в этом нет. Много информации не бывает. Зато сообщение можно сформулировать в терминах предметной области. Что несколько лучше чем в ноликах и единичках.
Хотя есть возможность сохранить только объекты-результат трансляции или только лексемы. Ведь объекты-инструкции хранят в себе все имена, классы и прочее. держать еще текст нет никакого смысла.

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

B>Почему не работают? Все как обычно, и даже можно перетаскивать объекты с панели инструментов. В нашей терминологии это классы, а дроп-даун создаются объекты.
Потому, что в процессе Copy-Paste программа является некорректной.

S>>Расскажите, как вы собираетесь бороться с отсутствием отдельной фазы компиляции, которая запускается вручную.
B>Почему отсутствует фаза компиляции? И фаза применения сценариев есть (она же интерпретация), и компиляция, и выполнение.
А зачем тогда фаза интерпретации, если есть компиляция? Какова её роль?

S>>Это всё понятно. Непонятно, зачем вы создаёте эту объект-инструкцию. Точнее, зачем вы на этом концентрируетесь.
B>Для того что б был понятен подход.
Вы сначала определите, какие задачи планируете решать.

B>А вот и не правильно. Во-первых почему бы инструкциям не иметь единый формат как и всем объектам?
Видите ли, тут действует "презумпция ненужности". В инженерном деле мотивация "почему бы и нет" не является достаточной. Надо сначала внятно объяснить "почему да", так как всё, без чего можно обойтись, безжалостно выбрасывается. По причине ограниченности ресурсов.

B>Никаких ограничений я не вижу. А во-вторых есть еще этап сопровождения и анализа уже готовой программы. Т.е. уже готовую программу можно рассматривать как документ и проверять ее логику или верификацию. Есть много чего можно сделать с готовой программой.
Совершенно верно. С готовой программой можно сделать очень много чего. См. например FxCop. Но при чём тут "объекты-инструкции"? Для чего они вам? Я же задал вам простые вопросы насчёт их "объектной" сущности. Но вы их почему-то избегаете. Я повторюсь:
— что является состоянием инструкций?
— какие сообщения они способны принимать?
— какие сообщения они передают другим объектам?

S>>Как это? Вопрос "зачем это нужно" здесь главный.
B>Если не нужно, то не делай. Но, просто есть возможность программой создавать программу.
Вот, вот я о том же и твержу: раз это не нужно, то не стоит этого делать. Зачем?
Возможность создавать программой программу никак не зависит от объектности инструкций как таковой. Это очевидно или придётся приводить примеры?

B>Эти имена и есть лексемы. Так что ничего плохого в этом нет.
Плохо то, что вы не понимаете, какую именно информацию вы хотите получать в результате, а проектируете от обратного. На разных этапах жизненного цикла программы нужны разные данные, с разной структурой. А вы почему-то зациклились на каких-то ранних стадиях жизненного цикла.

B>Много информации не бывает.
Ещё как бывает.
B>Зато сообщение можно сформулировать в терминах предметной области. Что несколько лучше чем в ноликах и единичках.
Совершенно непонятно, при чём тут предметная область. В предметной области нет никаких FOR и I.
B>Хотя есть возможность сохранить только объекты-результат трансляции или только лексемы. Ведь объекты-инструкции хранят в себе все имена, классы и прочее. держать еще текст нет никакого смысла.
Расскажите подробнее, какие именно объекты вы себе представляете результатом трансляции.

Да, кстати — вы со Smalltalk знакомы? Есть подозрение, что вы пытаетесь изобрести заново его среду.

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

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

B>>Почему не работают? Все как обычно, и даже можно перетаскивать объекты с панели инструментов. В нашей терминологии это классы, а дроп-даун создаются объекты.
S>Потому, что в процессе Copy-Paste программа является некорректной.
Ну, и пусть. Это ж редактирование.

S>>>Расскажите, как вы собираетесь бороться с отсутствием отдельной фазы компиляции, которая запускается вручную.
B>>Почему отсутствует фаза компиляции? И фаза применения сценариев есть (она же интерпретация), и компиляция, и выполнение.
S>А зачем тогда фаза интерпретации, если есть компиляция? Какова её роль?
Я уже говорил. Это может быть не только программа.

S>>>Это всё понятно. Непонятно, зачем вы создаёте эту объект-инструкцию. Точнее, зачем вы на этом концентрируетесь.
B>>Для того что б был понятен подход.
S>Вы сначала определите, какие задачи планируете решать.
Уже говорил.

B>>А вот и не правильно. Во-первых почему бы инструкциям не иметь единый формат как и всем объектам?
S>Видите ли, тут действует "презумпция ненужности". В инженерном деле мотивация "почему бы и нет" не является достаточной. Надо сначала внятно объяснить "почему да", так как всё, без чего можно обойтись, безжалостно выбрасывается. По причине ограниченности ресурсов.
Вот бывает так, что общность требует меньших ресурсов, чем анализ всяких уникальностей.

B>>Никаких ограничений я не вижу. А во-вторых есть еще этап сопровождения и анализа уже готовой программы. Т.е. уже готовую программу можно рассматривать как документ и проверять ее логику или верификацию. Есть много чего можно сделать с готовой программой.
S>Совершенно верно. С готовой программой можно сделать очень много чего. См. например FxCop. Но при чём тут "объекты-инструкции"? Для чего они вам? Я же задал вам простые вопросы насчёт их "объектной" сущности. Но вы их почему-то избегаете. Я повторюсь:
S>- что является состоянием инструкций?
S>- какие сообщения они способны принимать?
S>- какие сообщения они передают другим объектам?
Не зацикливайся. Возможность принимать и передавать это не обязательность. У меня нет понятий сообщения. У меня есть события.

S>>>Как это? Вопрос "зачем это нужно" здесь главный.
B>>Если не нужно, то не делай. Но, просто есть возможность программой создавать программу.
S>Вот, вот я о том же и твержу: раз это не нужно, то не стоит этого делать. Зачем?
S>Возможность создавать программой программу никак не зависит от объектности инструкций как таковой. Это очевидно или придётся приводить примеры?
Не надо примеров. Если хочется сделать сделай. Я не буду возражать.

B>>Эти имена и есть лексемы. Так что ничего плохого в этом нет.
S>Плохо то, что вы не понимаете, какую именно информацию вы хотите получать в результате, а проектируете от обратного. На разных этапах жизненного цикла программы нужны разные данные, с разной структурой. А вы почему-то зациклились на каких-то ранних стадиях жизненного цикла.
И на поздних. Я не зациклился. Если все понятно, то цель достигнута.

B>>Много информации не бывает.
S>Ещё как бывает.
Так и знал что прицепишься. Согласен. Но, оставил. Что б тебе веселее было возражать.

B>>Зато сообщение можно сформулировать в терминах предметной области. Что несколько лучше чем в ноликах и единичках.
S>Совершенно непонятно, при чём тут предметная область. В предметной области нет никаких FOR и I.
Но там есть имена. У меня инструкции могут имет имена, как и все объекты.
B>>Хотя есть возможность сохранить только объекты-результат трансляции или только лексемы. Ведь объекты-инструкции хранят в себе все имена, классы и прочее. держать еще текст нет никакого смысла.
S>Расскажите подробнее, какие именно объекты вы себе представляете результатом трансляции.
Я надеялся, что ты уже понял. И даже уверен.

S>Да, кстати — вы со Smalltalk знакомы? Есть подозрение, что вы пытаетесь изобрести заново его среду.
Знаком. Мало общего. Прежде всего мне не нравится взаимодействие объектов через сообщения. События у меня лучше формализованы и имеют более общий характер.

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

Я вижу интерес к теме. Но, диалог не получается. Мне приходится повторяться с ответами, а вам с вопросами. Может начать как-то по другому? Типа с начала. Или с документа. Или сделать паузу творческую. Что б созрели вопросы и ответы. Потому, что вы наверняка заметили что разговор стал напряжным. Извиняюсь. Жду ваших мыслей по методу продолжения разговора. Еще раз извиняюсь за не сдержаность.

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


S>>>Расскажите, как вы собираетесь бороться с отсутствием отдельной фазы компиляции, которая запускается вручную.
B>>Почему отсутствует фаза компиляции? И фаза применения сценариев есть (она же интерпретация), и компиляция, и выполнение.
S>А зачем тогда фаза интерпретации, если есть компиляция? Какова её роль?
Интерпретация (или у меня выполнение сценария) это выполнения операторов имеющих значения на этапе компиляции. И может выполняет роль текстового процессора, в частном случае могут выполняться и процедуры в качестве макросов, создавая участок программы генерируя текст. Условные операторы могут включать или удалять текст в зависимости от значения условий. Могут выполняться циклы, так же формируя текст программы. Понятное дело операторы сложения и т.д. выполняющиеся на этапе выполнения сценария не что иное как интерпретатор в классическом смысле этого слова. Т.е. все зависит что ты наваяем в качестве сценария и какие данные ему подадим. Напомню, что данные и структуры описаные в синтаксисе этого же языка, могут формировать сценарий. Так же данные определенный оператором Var и константы (по большому счету все статические объекты имеющие значение) могут быть данными для выполнения операторов в режиме выполнения сценария. Напомню объекты определенные операторами Dim и New не существуют на этапе выполнения сценария. Они будут созданы на этапе выполнения. Таким способом мы имеем и интерпретатор и компилятор. Все зависит от того как определим данные.

Здравствуйте, batu, Вы писали:
B>Ну, и пусть. Это ж редактирование.
А куда денутся объекты?
Вот у меня строка

For I=0 To N { J+=1 Z=X*Y}

Из неё, вроде бы, получено множество объектов. Ну там — символы, лексемы, объект для команды For и прочее.
А теперь я беру и начинаю редактировать строку. Например, удаляю букву o. Или, ещё лучше, удаляю букву J. Куда денутся уже созданные объекты для For и J?

S>>А зачем тогда фаза интерпретации, если есть компиляция? Какова её роль?
B>Я уже говорил. Это может быть не только программа.
По-прежнему не понимаю. Зачем фаза интерпретации не-программе?

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

B>Не зацикливайся. Возможность принимать и передавать это не обязательность. У меня нет понятий сообщения. У меня есть события.
Это как раз обязательность. Если у инструкций нет состояния и нет обмена сообщениями (или событиями — не важно) то это не объекты. Это понятно, или надо дальше разжёвывать?

S>>Возможность создавать программой программу никак не зависит от объектности инструкций как таковой. Это очевидно или придётся приводить примеры?
B>Не надо примеров. Если хочется сделать сделай. Я не буду возражать.
Что именно "сделать"?

B>И на поздних. Я не зациклился. Если все понятно, то цель достигнута.
Пока ничего не понятно.

S>>Совершенно непонятно, при чём тут предметная область. В предметной области нет никаких FOR и I.
B>Но там есть имена. У меня инструкции могут имет имена, как и все объекты.
Где есть имена?

B>Я надеялся, что ты уже понял. И даже уверен.
Нет, я пока не понимаю.
S>>Да, кстати — вы со Smalltalk знакомы? Есть подозрение, что вы пытаетесь изобрести заново его среду.
B>Знаком. Мало общего. Прежде всего мне не нравится взаимодействие объектов через сообщения. События у меня лучше формализованы и имеют более общий характер.
Ну, попробуйте рассказать про события.

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


B>Интерпретация (или у меня выполнение сценария) это выполнения операторов имеющих значения на этапе компиляции. И может выполняет роль текстового процессора, в частном случае могут выполняться и процедуры в качестве макросов, создавая участок программы генерируя текст. Условные операторы могут включать или удалять текст в зависимости от значения условий. Могут выполняться циклы, так же формируя текст программы. Понятное дело операторы сложения и т.д. выполняющиеся на этапе выполнения сценария не что иное как интерпретатор в классическом смысле этого слова. Т.е. все зависит что ты наваяем в качестве сценария и какие данные ему подадим. Напомню, что данные и структуры описаные в синтаксисе этого же языка, могут формировать сценарий. Так же данные определенный оператором Var и константы (по большому счету все статические объекты имеющие значение) могут быть данными для выполнения операторов в режиме выполнения сценария. Напомню объекты определенные операторами Dim и New не существуют на этапе выполнения сценария. Они будут созданы на этапе выполнения. Таким способом мы имеем и интерпретатор и компилятор. Все зависит от того как определим данные.
Это всё понятно. Непонятно — зачем это нужно. Если нужно — возьмите творческую паузу. Но пока вы не придумаете внятные ответы на вопросы "зачем", обсуждения языка не получится.

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

S>Здравствуйте, batu, Вы писали:
B>>Ну, и пусть. Это ж редактирование.
S>А куда денутся объекты?
S>Вот у меня строка

S>

S>For I=0 To N { J+=1 Z=X*Y}
S>

S>Из неё, вроде бы, получено множество объектов. Ну там — символы, лексемы, объект для команды For и прочее.
S>А теперь я беру и начинаю редактировать строку. Например, удаляю букву o. Или, ещё лучше, удаляю букву J. Куда денутся уже созданные объекты для For и J?
Редактируются. Могут и удалится. Я вопрос понял. Не рассказывать же алгоритм редактирования. Да, там получается несколько сложнее, чем в обычном текстовом редакторе. Но, оно того стоит.

S>>>А зачем тогда фаза интерпретации, если есть компиляция? Какова её роль?
B>>Я уже говорил. Это может быть не только программа.
S>По-прежнему не понимаю. Зачем фаза интерпретации не-программе?
Например, генерировать текст. Я еще страшнее вещи скажу. Объекты текстового (и любого другого документа) могут иметь события, процедуры обработки событий. Т.е. как все у браузера. Т.е. этот редактор-транслятор одновременно и браузер.

B>>Уже говорил.
S>Не вижу.
B>>Вот бывает так, что общность требует меньших ресурсов, чем анализ всяких уникальностей.
S>Бывает. Но любую экономию нужно доказывать.
Хорошо. Скорость выполнения команд ниже раза в 4. Памяти требуется на порядок меньше. Виртуальная машина проще и меньше на порядок от той же джавы. Уровень сложности гораздо ниже. Здесь цифры привести не могу. Когда вникнешь в группы, события и т.д. поймешь. Потому что здесь мультипликативный эффект.

B>>Не зацикливайся. Возможность принимать и передавать это не обязательность. У меня нет понятий сообщения. У меня есть события.
S>Это как раз обязательность. Если у инструкций нет состояния и нет обмена сообщениями (или событиями — не важно) то это не объекты. Это понятно, или надо дальше разжёвывать?
Не надо разжевывать. Очевидно, что это не так. Совсем не обязательно уже созданый объект должен изменять состояние и чем-то обмениваться. Может вся ценность объекта в том, что он не изменяет состояние, и не обменивается сообщениями. То, у тебя предрассудки.

S>>>Возможность создавать программой программу никак не зависит от объектности инструкций как таковой. Это очевидно или придётся приводить примеры?
B>>Не надо примеров. Если хочется сделать сделай. Я не буду возражать.
S>Что именно "сделать"?
Программу, которая создает другую программу. Мне пример не нужен. Я и так знаю что это можно сделать.

S>>>Совершенно непонятно, при чём тут предметная область. В предметной области нет никаких FOR и I.
B>>Но там есть имена. У меня инструкции могут имет имена, как и все объекты.
S>Где есть имена?
Каждый объект имеет свойсто Name.

B>>Я надеялся, что ты уже понял. И даже уверен.
S>Нет, я пока не понимаю.
S>>>Да, кстати — вы со Smalltalk знакомы? Есть подозрение, что вы пытаетесь изобрести заново его среду.
B>>Знаком. Мало общего. Прежде всего мне не нравится взаимодействие объектов через сообщения. События у меня лучше формализованы и имеют более общий характер.
S>Ну, попробуйте рассказать про события.
Запросто. Хотя это есть в документе, и здесь я уже пару раз копи-пастил оттуда. Отдельно отвечу. Что б не путаться.

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

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

S>Это всё понятно. Непонятно — зачем это нужно. Если нужно — возьмите творческую паузу. Но пока вы не придумаете внятные ответы на вопросы "зачем", обсуждения языка не получится.
Жизнь покажет что получится, что не получится..

Здравствуйте, Sinclair, Вы писали:
S>Ну, попробуйте рассказать про события.
Механизм событий является отличительной чертой языка Lada именно благодаря этому, язык называется аспектным. События определяются объектами класса Event. Класс Event имеет свойства Condition, Connection, Fire и Event. Свойство Condition это выражение, при истинности которого событие считается происшедшим и запускается процедура обработки события, если она определена (значние свойства Event). Отсутствие значения в свойстве Condition означает безусловное событие. Проверка свойства Condition происходит при выполнении событий определенных свойством Connection, которое связывает данное событие со списком внешних событий (подписаться на событие). Таким образом, свойство Connection представляет собой группу ссылок на события, к которым подписывается создаваемое событие. Так как свойство Connection представляет собой группу событий, то запуск проверки свойства Condition может происходить от срабатывания одного события из группы или от срабатывания всех событий группы. Группа событий в свойстве Connection называется комплектом. И соответственно комплекты бывают вида И/Или. Эти два вида комплектов отличаются методом объединения в группы. Режим Или определяется группой в квадратных скобках с вертикальной чертой. Остальные варианты группировки определяют режим И.
Свойство Event содержит группу операторов для выполнения, если процедура обработки события определена в самом событии или ссылку на процедуру или блок обработки события. По этой причине процедура обработки события самостоятельное понятие и не является обязательно процедурой. Это может быть и блок, перехватывающий события. Таким методом происходит перехват и обработка ошибок, которые тоже события.
Универсальной процедурой обработки ошибок является оператор-процедура Error. Стандартными параметрами этой процедуры являются объект инициатор события — ошибки (Sender) и само событие (Event), а именем служит путь к объекту контроля.
Создание объекта события оператором New заключается не только в выделении места в памяти для созданного объекта, но и ставит данное событие под контроль обработчика событий.
При создании события оператором Event событие выполняется как оператор остановливающий выполнение программы до выполнения события. При выполнении события, может быть выполнена процедура обработки, если она есть, и продолжается выполнение программы. Таким способом осуществляется синхронизация. Однако само ожидание события так же передается обработчику события, что предотвращает модификацию оператора при одновременом использовании этого участка программы несколькими пользователями.
Оператор Raise инициирует событие независимо от возникновения событий Connection и значения Condition.

Пример 10.1. Событие «Полдень» с подпиской к таймеру.

New Event Noon
{Condition =Timer.Now=12.00Time)
Connection.Add(Timer.Change)
Event =:MsgBox(Полдень,1)
}

В данном примере событие является объектом, создаваемым вне программы и при изменении значения таймера (событие Timer.Change) происходит проверка условия Condition на 12 часов. При выполнении условия появится сообщение “Полдень”.

Пример 10.2. Событие-синхронизация «Полдень» с подпиской к таймеру.

Event
{Condition =Timer.Now=12.00Time)
Connection.Add(Timer.Change)
Event =:MsgBox(Полдень,1)
}

А здесь событие является оператором в программе. Выполняющаяся программа дойдет до этого оператора и прекратит свое выполнение до 12 часов. В 12 выдаст сообщение и продолжит выполнение.
Определяя связь (свойство Connection) объекта 1 с объектом 2, мы подразумеваем, что если выполняется некое условие связи (и/или события) в объекте 2, то информация об этом факте должна быть передана объекту 1 для дальнейшего анализа. Стало быть, инициатором передачи этой информации является объект 2. Для того что бы сообщить объекту 2 о том, что объект 1 нуждается в информации о выполнении данного и формируется свойство Fire объекта 2. Свойство Fire (список подписки) не доступно пользователю и формируется теговой машиной. По этому свойству осуществляется реализация подписки на событие. Т.е. при возникновении события в объекте 2 проверяется список рассылки Fire и по этому списку передается информация подписавшимся событиям.
Ссылки на процедуры обработки события находятся в объекте 1, а параметры для передачи в эти процедуры (если в них есть необходимость) формируются в объекте 2. Стало быть, информация о требуемых параметрах должна поступать в объект 1 в момент возникновения события. Информация о запрашиваемых параметрах может отсутствовать, тогда если объект 2 в пределах досягаемости ссылки на объект инициатор события передается ссылка на него и информация о самом событии.
Необходимо обратить внимание, что объектом источником является объект 2, а объект 1 является приемником. Т.е. событие мы создаем в объекте-приемнике или в классе, который создаст объект-приемник.
Процедура обработки события может быть задана как внутри класса, так и для каждого объекта. Приведем пример определения события EndText. Допустим мы анализируем текст длиной Len и с индексом анализируемого символа Ind. При каждом анализе нам необходимо проверять символ, не последний ли он в тексте. Иногда сложно организовывать проверку на конец текста каждый раз, да и документ редактируется, что изменяет его размер. Можно потерять проверку при редактировании или забыть её выполнить. Создадим событие конец текста (EndText). Подключив процедуру обработки этого события, мы гарантированы от проблем с анализом счетчика на конец текста при любом редактировании.

Пример 10.3. Определение события EndText.

Dim Len: Integer[2] ' Длина текста
Dim Ind: Integer[2] ' Индекс проверяемого символа
New EndText: Event ' Создание события EndText
{Condition=: (Len=Ind) Connection.Add(Ind.Change)
}

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

B>>А если целевая машина принимает на входе объекты? Логично тогда ожидать что компилятор должен создать объекты?
S>Ну, во-первых, я с такими целевыми машинами не встречался. Они все до единой, по какому-то странному сговору, принимают набор инструкций на некотором языке.

Машина Пролога с тобой не согласна, она оперирует довольно высокоуровневыми структурами, вряд ли удобными для описания ассемблерами, типа MSIL.

Здравствуйте, batu, Вы писали:
B>Редактируются. Могут и удалится. Я вопрос понял. Не рассказывать же алгоритм редактирования. Да, там получается несколько сложнее, чем в обычном текстовом редакторе. Но, оно того стоит.
Пока непонятно, за счёт чего оно того стоит.

S>>По-прежнему не понимаю. Зачем фаза интерпретации не-программе?
B>Например, генерировать текст. Я еще страшнее вещи скажу. Объекты текстового (и любого другого документа) могут иметь события, процедуры обработки событий. Т.е. как все у браузера. Т.е. этот редактор-транслятор одновременно и браузер.
И? Какое в этом преимущество?

B>Хорошо. Скорость выполнения команд ниже раза в 4. Памяти требуется на порядок меньше. Виртуальная машина проще и меньше на порядок от той же джавы. Уровень сложности гораздо ниже. Здесь цифры привести не могу. Когда вникнешь в группы, события и т.д. поймешь. Потому что здесь мультипликативный эффект.
Ну снизили вы скорость выполнения команд — это что, преимущество что ли? Обычно все наоборот, увеличить скорость хотят.
Памяти нужно меньше чем кому? Пока что я вижу только необоснованный рост расходов.

B>Не надо разжевывать. Очевидно, что это не так. Совсем не обязательно уже созданый объект должен изменять состояние и чем-то обмениваться. Может вся ценность объекта в том, что он не изменяет состояние, и не обменивается сообщениями. То, у тебя предрассудки.
Все заблуждения начинаются со слов "очевидно, что...". Я вам объясняю элементарные вещи, например, определение термина "объект".
Вся ценность объекта как раз в том, что он может изменять состояние и обменивается сообщениями. Если этого нет, то нет и семантики объекта. Можно говорить, к примеру, о value-type семантике, и об Abstract Data Types вместо классов.

B>Программу, которая создает другую программу. Мне пример не нужен. Я и так знаю что это можно сделать.
Отлично. То есть преимущества у вашего языка перед другими собственно нет.

S>>>>Совершенно непонятно, при чём тут предметная область. В предметной области нет никаких FOR и I.
B>>>Но там есть имена. У меня инструкции могут имет имена, как и все объекты.
S>>Где есть имена?
B>Каждый объект имеет свойсто Name.
И? Какое отношение это имеет к предметной области?

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

B>Здравствуйте, Sinclair, Вы писали:
S>>Ну, попробуйте рассказать про события.
B>Механизм событий является отличительной чертой языка Lada именно благодаря этому, язык называется аспектным.
Ага, я так понимаю, термин "аспект" вы тоже используете своим способом, несовместимым со всем остальным человечеством? Ну то есть AOP к аспектности в вашем языке никакого отношения не имеет. Что ж, этот подход почти гарантирует вам проблемы в коммуникации с другими разработчиками.

B>События определяются объектами класса Event. Класс Event имеет свойства Condition, Connection, Fire и Event.
А зачем вносить это на уровень языка? Здесь пока нет ничего такого, что нельзя было бы изобразить при помощи библиотеки в обычном языке общего назначения.
B>При создании события оператором Event событие выполняется как оператор остановливающий выполнение программы до выполнения события. При выполнении события, может быть выполнена процедура обработки, если она есть, и продолжается выполнение программы. Таким способом осуществляется синхронизация. Однако само ожидание события так же передается обработчику события, что предотвращает модификацию оператора при одновременом использовании этого участка программы несколькими пользователями.
B>Оператор Raise инициирует событие независимо от возникновения событий Connection и значения Condition.

B>Пример 10.1. Событие «Полдень» с подпиской к таймеру.

B>New Event Noon
B>{Condition =Timer.Now=12.00Time)
B> Connection.Add(Timer.Change)
B> Event =:MsgBox(Полдень,1)
B>}

B>В данном примере событие является объектом, создаваемым вне программы и при изменении значения таймера (событие Timer.Change) происходит проверка условия Condition на 12 часов. При выполнении условия появится сообщение “Полдень”.
Отличный пример. Надеюсь, понятно, что производительность такого события будет чудовищно низкой? Достаточно вставить в ожидание пару десятков таких таймеров, чтобы CPU больше ничего не делал.
Кстати, в контексте какого потока будет выполнен код Event, когда придёт время срабатывать?

B>Пример 10.2. Событие-синхронизация «Полдень» с подпиской к таймеру.

B>Event
B>{Condition =Timer.Now=12.00Time)
B> Connection.Add(Timer.Change)
B> Event =:MsgBox(Полдень,1)
B>}

B>А здесь событие является оператором в программе. Выполняющаяся программа дойдет до этого оператора и прекратит свое выполнение до 12 часов. В 12 выдаст сообщение и продолжит выполнение.

B>Пример 10.3. Определение события EndText.

B>Dim Len: Integer[2] ' Длина текста
B>Dim Ind: Integer[2] ' Индекс проверяемого символа
B>New EndText: Event ' Создание события EndText
B> {Condition=: (Len=Ind) Connection.Add(Ind.Change)
B> }
Я что-то не помню: вам уже сказали, что в примере есть ошибка? Ну, то есть нет связи с Len.Change?

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

S>Здравствуйте, batu, Вы писали:
B>>Редактируются. Могут и удалится. Я вопрос понял. Не рассказывать же алгоритм редактирования. Да, там получается несколько сложнее, чем в обычном текстовом редакторе. Но, оно того стоит.
S>Пока непонятно, за счёт чего оно того стоит.
Наверное имел ввиду, для чего? Например, для того что бы иметь возможность просмотреть свойства объекта в интересующем нас смысле. А их несколько.

For I=0 To 20 {...}

1. I — Объект-Буква. Соответственно его свойства это шрифт, цвет и т.д.
2. I- Объект-лексема. Слово. Соответственно со своими свойствами. Язык и т.д.
3. I-Свойство Name объекта класса For.

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

B>>Хорошо. Скорость выполнения команд ниже раза в 4. Памяти требуется на порядок меньше. Виртуальная машина проще и меньше на порядок от той же джавы. Уровень сложности гораздо ниже. Здесь цифры привести не могу. Когда вникнешь в группы, события и т.д. поймешь. Потому что здесь мультипликативный эффект.
S>Ну снизили вы скорость выполнения команд — это что, преимущество что ли? Обычно все наоборот, увеличить скорость хотят.
Увеличение скорости выполнения каждой команды не всегда увеличение скорости решения задачи. Особенно когда появляются новые возможности.
S>Памяти нужно меньше чем кому? Пока что я вижу только необоснованный рост расходов.
А я вижу обоснованый. Собственно и занимаюсь этим. Обосновываю.

S>Все заблуждения начинаются со слов "очевидно, что...". Я вам объясняю элементарные вещи, например, определение термина "объект".
S>Вся ценность объекта как раз в том, что он может изменять состояние и обменивается сообщениями. Если этого нет, то нет и семантики объекта. Можно говорить, к примеру, о value-type семантике, и об Abstract Data Types вместо классов.
Совсем не обязательно что бы уже созданый объект должен обязательно изменять состояние и чем-то обмениваться. Может вся ценность объекта в том, что он не изменяет состояние, и не обменивается сообщениями.

B>>Программу, которая создает другую программу. Мне пример не нужен. Я и так знаю что это можно сделать.
S>Отлично. То есть преимущества у вашего языка перед другими собственно нет.
В этом смысле нет. Но вот когда начнешь делать увидишь преимущества.

S>>>>>Совершенно непонятно, при чём тут предметная область. В предметной области нет никаких FOR и I.
B>>>>Но там есть имена. У меня инструкции могут имет имена, как и все объекты.
S>>>Где есть имена?
B>>Каждый объект имеет свойсто Name.
S>И? Какое отношение это имеет к предметной области?
Есть обоснованое подозрение, что имена классов и объектов будут близки к предметной области.

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

V>Машина Пролога с тобой не согласна, она оперирует довольно высокоуровневыми структурами, вряд ли удобными для описания ассемблерами, типа MSIL.
А чем они описываются?

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

B>Наверное имел ввиду, для чего? Например, для того что бы иметь возможность просмотреть свойства объекта в интересующем нас смысле. А их несколько.
B>

B>For I=0 To 20 {...}
B>

B>1. I — Объект-Буква. Соответственно его свойства это шрифт, цвет и т.д.
B>2. I- Объект-лексема. Слово. Соответственно со своими свойствами. Язык и т.д.
B>3. I-Свойство Name объекта класса For.
Не вижу ничего интересного. К примеру, цвет буквы I никак не интересует компилятор. А систему отображения не интересует семантика буквы I.
Пока эти две системы живут в непересекающихся мирах — всё хорошо. К примеру, я могу не мучиться с чтением программы, которую автор написал используя отсутствующий на моей машине шрифт. И я не испытываю проблем из-за того, что кто-то выбрал кегль 2pt, который невозможно разборчиво отобразить на моём мониторе. Это понятно?

S>>>>По-прежнему не понимаю. Зачем фаза интерпретации не-программе?
B>>>Например, генерировать текст. Я еще страшнее вещи скажу. Объекты текстового (и любого другого документа) могут иметь события, процедуры обработки событий. Т.е. как все у браузера. Т.е. этот редактор-транслятор одновременно и браузер.
S>>И? Какое в этом преимущество?
B>А то, что на этом языке можно и сайты создавать, и программы, создавать и редактировать объекты для баз данных и вообще все делать.
Интересно. Вот, к примеру, есть такая программа — Visual Studio. В ней можно и сайты создавать, и программы, создавать и редактировать объекты для баз данных и вообще все делать. Чем ваш редактор-браузер-транслятор будет лучше?

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

S>>Памяти нужно меньше чем кому? Пока что я вижу только необоснованный рост расходов.
B>А я вижу обоснованый. Собственно и занимаюсь этим. Обосновываю.
Пока я не вижу никаких обоснований, кроме утверждений типа "очевидно, что" и абстрактных рассуждений.

S>>Все заблуждения начинаются со слов "очевидно, что...". Я вам объясняю элементарные вещи, например, определение термина "объект".
S>>Вся ценность объекта как раз в том, что он может изменять состояние и обменивается сообщениями. Если этого нет, то нет и семантики объекта. Можно говорить, к примеру, о value-type семантике, и об Abstract Data Types вместо классов.
B> Совсем не обязательно что бы уже созданый объект должен обязательно изменять состояние и чем-то обмениваться. Может вся ценность объекта в том, что он не изменяет состояние, и не обменивается сообщениями.
Вы вообще читаете то, что я вам пишу? Вы смысл слова "определение" знаете?
B>В этом смысле нет. Но вот когда начнешь делать увидишь преимущества.
Непонятно.

S>>И? Какое отношение это имеет к предметной области?
B>Есть обоснованое подозрение, что имена классов и объектов будут близки к предметной области.
И где эти обоснования? Ну, обоснуйте мне, что имя цикла For, которое вы там выбрали на основе имени переменной, будет близко к предметной области. С учётом того, что в предметной области вообще никаких циклов нет.

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

V>>Машина Пролога с тобой не согласна, она оперирует довольно высокоуровневыми структурами, вряд ли удобными для описания ассемблерами, типа MSIL.
S>А чем они описываются?

Структурами того языка, на котором написана сама реализация полога. Т.е. где-то — кортежи Лиспа, а где-то — АПИ в C-стиле.

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

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

S>Не вижу ничего интересного. К примеру, цвет буквы I никак не интересует компилятор. А систему отображения не интересует семантика буквы I.
А может и интересовать. Или другие свойства. Такие как надстрочное или подстрочное значение. Мой компилятор это обнаруживает. Да и не все равно ему.
S>Пока эти две системы живут в непересекающихся мирах — всё хорошо. К примеру, я могу не мучиться с чтением программы, которую автор написал используя отсутствующий на моей машине шрифт. И я не испытываю проблем из-за того, что кто-то выбрал кегль 2pt, который невозможно разборчиво отобразить на моём мониторе. Это понятно? Понятно. Только я ж привел пример. Это ж могут быть и не буквы, а знаки обозначающие объект любого класса. Есть и такие возможности.

S>>>>>По-прежнему не понимаю. Зачем фаза интерпретации не-программе?
B>>>>Например, генерировать текст. Я еще страшнее вещи скажу. Объекты текстового (и любого другого документа) могут иметь события, процедуры обработки событий. Т.е. как все у браузера. Т.е. этот редактор-транслятор одновременно и браузер.
S>>>И? Какое в этом преимущество?
B>>А то, что на этом языке можно и сайты создавать, и программы, создавать и редактировать объекты для баз данных и вообще все делать.
S>Интересно. Вот, к примеру, есть такая программа — Visual Studio. В ней можно и сайты создавать, и программы, создавать и редактировать объекты для баз данных и вообще все делать. Чем ваш редактор-браузер-транслятор будет лучше?
Можно. На разных языках. А у меня один. И редактор один.

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

S>>>Памяти нужно меньше чем кому? Пока что я вижу только необоснованный рост расходов.
B>>А я вижу обоснованый. Собственно и занимаюсь этим. Обосновываю.
S>Пока я не вижу никаких обоснований, кроме утверждений типа "очевидно, что" и абстрактных рассуждений.
События прочитал? А правила группирования? .

S>Вы вообще читаете то, что я вам пишу? Вы смысл слова "определение" знаете?
А какой ответ вы ожидаете?
Я ж не возражал против определения которое вы привели. Я привел свое. Потому как у меня сообщений нет. Есть события. И, наконец, нигде в определении нет обязательства изменять состояние. Это формулируется как ВОЗМОЖНОСТЬ.

S>>>И? Какое отношение это имеет к предметной области?
B>>Есть обоснованое подозрение, что имена классов и объектов будут близки к предметной области.
S>И где эти обоснования? Ну, обоснуйте мне, что имя цикла For, которое вы там выбрали на основе имени переменной, будет близко к предметной области. С учётом того, что в предметной области вообще никаких циклов нет.

Да запросто

ForEach "Проверка всех бутылок в ящике" In Ящик {}