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

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

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

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

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

B>>События определяются объектами класса Event. Класс Event имеет свойства Condition, Connection, Fire и Event.
S>А зачем вносить это на уровень языка? Здесь пока нет ничего такого, что нельзя было бы изобразить при помощи библиотеки в обычном языке общего назначения.
Все уже где-то есть. Я не претендую на гениальность. Просто у меня это определено так. Мне кажется, что так будет естественней.

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 часов. При выполнении условия появится сообщение “Полдень”.
S>Отличный пример. Надеюсь, понятно, что производительность такого события будет чудовищно низкой? Достаточно вставить в ожидание пару десятков таких таймеров, чтобы CPU больше ничего не делал.
Это ж пример, а не конкурс на эффективность. На примере часов очень естественно объянять природу событий.
S>Кстати, в контексте какого потока будет выполнен код Event, когда придёт время срабатывать?
В контексте объекта в котором определена процедура или блок. Есть варианты необходимые, например, для событий Error. Думаю понятно по какой причине.


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>> }
S>Я что-то не помню: вам уже сказали, что в примере есть ошибка? Ну, то есть нет связи с Len.Change?
Посмотрите в тексте документа. Там есть примеры когда изменяется длина. Очень приятно что вы быстро въехали в эту тему.

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

B>А может и интересовать. Или другие свойства. Такие как надстрочное или подстрочное значение. Мой компилятор это обнаруживает. Да и не все равно ему.
Если компилятор это обнаруживает, то это — не шрифт.
Шрифт — это, к примеру, Tahoma 9pt Bold. Или, скажем, Consolas 8.25pt italic.
Какому компилятору это важно?

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

B>Можно. На разных языках. А у меня один. И редактор один.
Ну да. Пока что получается, что описывать векторную графику удобнее на одном языке, а запросы к базе — на другом.

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

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

B>А какой ответ вы ожидаете?
B>Я ж не возражал против определения которое вы привели. Я привел свое.
Во-первых, не привели. Во-вторых, использование общепринятых терминов в необщепринятых смыслах — один из лучших способов добиться непонимания.

B>Потому как у меня сообщений нет.
Вы смысл слова "сообщение" в определении Алана Кея понимаете? Или вы опять подразумеваете под "сообщением" что-то своё, не то, что Алан Кей?

B>Да запросто
B>ForEach "Проверка всех бутылок в ящике" In Ящик {}
1. Я правильно понимаю, что у вас теперь переменная цикла называется "Проверка всех бутылок в ящике"?
2. Зачем вообще имя этому циклу?
3. Вы написали пустой цикл. Это намеренное решение — дать имя фрагменту кода, который ничего не делает?
Если нет, то я вас разочарую: такие изобретения хорошо смотрятся на выдуманных примерах. Реальный код содержит очень-очень мало того, чему есть аналог в предметной области. Откройте любой исходник, который у вас под рукой, и вы увидите, что из предметной области там ничего нету. Программа соответствует некой модели, которая в свою очередь очень опосредованно связана с предметной областью.

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

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

B>>А может и интересовать. Или другие свойства. Такие как надстрочное или подстрочное значение. Мой компилятор это обнаруживает. Да и не все равно ему.
S>Если компилятор это обнаруживает, то это — не шрифт.
Это свойства.
S>Шрифт — это, к примеру, Tahoma 9pt Bold. Или, скажем, Consolas 8.25pt italic.
S>Какому компилятору это важно?
Моему важно. У меня есть подстрочные, надстрочные значения и цветом можно выделять, например, комментарии.
И правила описания грамматик у меня свои. Ориентированы на ООП. В понятия можно включать предикаты. Потому можно проверять и наличие и значения свойств объекта. Буква- частный случай объектов.

S>Но вы приводите не эти возможности, а какие-то абстрактные свойства символа, которых у него потенциально может быть очень много.
Правильно. Может быть очень много.

B>>Можно. На разных языках. А у меня один. И редактор один.
S>Ну да. Пока что получается, что описывать векторную графику удобнее на одном языке, а запросы к базе — на другом.
У меня на одном. Хотя не могу быть специалистом во всех областях, но уверен что все можно конвертировать в классы-объекты.

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

B>>Потому как у меня сообщений нет.
S>Вы смысл слова "сообщение" в определении Алана Кея понимаете? Или вы опять подразумеваете под "сообщением" что-то своё, не то, что Алан Кей?
Поюморю. Вчера смотрел фильм про Лысенко. Там его спросили про какого-то ученого Z, так он ответил
-Не знаю я никакого Z. Я его на огороде не видел
Да согласен я с Аланом Кейем.
Объект — базовая единица объектно-ориентированной системы.
Объекты могут обладать состоянием.
Посылка сообщения — единственный способ обмена информацией между объектами.


Что ж теперь уже ничего другого сказать нельзя? Ничего против его понимания сообщений не имею. Просто считаю что он сам бы согласился с тем, что механизм событий больше подходит. Как это реализовано в smalltalk мне не нравится. Хотя нет никаких противоречий.
А насчет состояний обрати внимание
Объекты МОГУТ обладать состоянием. Могут, а не обязаны. Кстати, состояния инструкции таки меняют.



B>>Да запросто
B>>ForEach "Проверка всех бутылок в ящике" In Ящик {}
S>1. Я правильно понимаю, что у вас теперь переменная цикла называется "Проверка всех бутылок в ящике"?
S>2. Зачем вообще имя этому циклу?
S>3. Вы написали пустой цикл. Это намеренное решение — дать имя фрагменту кода, который ничего не делает?
Не фрагменту кода, а объекту класса ForEach. И попрошу заметить синтаксис общий.
"Имя класса" "Имя объекта"
Как и у For I=0 и Dim Int I=0

S>Программа соответствует некой модели, которая в свою очередь очень опосредованно связана с предметной областью.
Не буду спорить. Так как ты сформулировал даже правильней. В каких терминах хочешь получать информацию, так и пиши. Кроме как от написанного информацию брать неоткуда.

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

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

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

Да, входное текстовое представление разбирается и хранится в виде структур в некоей "базе знаний", по которой затем работает Пролог-машина.

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


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

Добавлю чуть подробнее. Фактически, классический Пролог содержит только 2 вида структур: факты и правила преобразований одних фактов в другие (они же утвержденияи). Последнее бывают разделяют еще на подвиды, но это не принципиально. Задача Пролог-машины, при наличии данных фактов и правил их преобразования (правил вывода), проверить некое другое входное утверждение (цель), построив цепочку "рассуждений". Например, нет ничего проще писать Парсеры на прологе, ибо выходная "цепочка рассуждений" при парсинге неких данных — это готовое AST.

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

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


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

V>Добавлю чуть подробнее. Фактически, классический Пролог содержит только 2 вида структур: факты и правила преобразований одних фактов в другие (они же утвержденияи). Последнее бывают разделяют еще на подвиды, но это не принципиально. Задача Пролог-машины, при наличии данных фактов и правил их преобразования (правил вывода), проверить некое другое входное утверждение (цель), построив цепочку "рассуждений". Например, нет ничего проще писать Парсеры на прологе, ибо выходная "цепочка рассуждений" при парсинге неких данных — это готовое AST.

Лень читать все, компилятор под этот язык уже есть ?

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

S>>Какому компилятору это важно?
B>Моему важно. У меня есть подстрочные, надстрочные значения и цветом можно выделять, например, комментарии.
У вас всё задом наперёд. В привычных средах не нужно выделять цветом комментарии. Выделение цветом делается автоматически, оно вторично по отношению к семантике комментариев. Я уже встречал на этом форуме авторов, которые пропагандировали "ручную" раскраску программ. Увы, реальных программистов убедить не удалось. Поясняю: в суровой реальности шансы на успех имеют решения, которые позволяют делать меньше.
Вот примеры матов в один ход:
— В моём языке я могу указывать, какую переменную положить в какой регистр!
— Точнее, ты должен указывать, какую переменную положить в какой регистр. Поэтому мы выбираем языки, в которых можно не указывать в какой регистр попадёт переменная, а компилятор достаточно умен, чтобы выбрать это за нас.

— В моей базе данных я могу указывать, какую физическую операцию нужно применять для джойна!
— Точнее, ты вынужден выбирать физическую реализацию для джойна. Поэтому мы выбираем СУБД, в которых можно не указывать план запроса, а движок достаточно умён, чтобы построить его за нас.

Понятно? Точно так же раскраски кода в фантастические цвета неинтересны. Как минимум до тех пор, пока не приведён убедительный пример использования, и обосновано, почему такой эффект нельзя получить в других подходах.

B>И правила описания грамматик у меня свои. Ориентированы на ООП. В понятия можно включать предикаты. Потому можно проверять и наличие и значения свойств объекта. Буква- частный случай объектов.
Я уже понял, что всё — частный случай объектов. Непонятно, в общем-то, зачем.

B>Правильно. Может быть очень много.
А зачем?

B>У меня на одном. Хотя не могу быть специалистом во всех областях, но уверен что все можно конвертировать в классы-объекты.
Я понимаю, что вы заставляете всех писать на одном языке. Результат конверсии "всего" в классы-объекты вам уже приводили — XML. Нет такого документа, который нельзя было бы засунуть в XML. Это не означает, что XML способен заменить всё что угодно.

S>>Прочитал я события. И что? Откуда возьмется экономия? И, главное, по сравнению с чем?
B>Прочитай тогда правила группирования. Я думаю что ты поймешь.
Прочитал. Я тупой — объясните мне.

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


B> Что ж теперь уже ничего другого сказать нельзя? Ничего против его понимания сообщений не имею. Просто считаю что он сам бы согласился с тем, что механизм событий больше подходит.
Для чего он больше подходит?
Ок, вижу, понимание не налаживается. У вас вызовы методов есть? Есть. Это — частный случай общего понятия "посылка сообщения". Значит, само понятие посылки сообщения (отличное от вашей концепции событий) в языке уже есть.

B>А насчет состояний обрати внимание
B>Объекты МОГУТ обладать состоянием. Могут, а не обязаны. Кстати, состояния инструкции таки меняют.
Ну вот я уже в четвёртый раз спрашиваю: где изменения состояния у инструкций? Сосредоточьтесь.

B>>>Да запросто
B>>>ForEach "Проверка всех бутылок в ящике" In Ящик {}
S>>1. Я правильно понимаю, что у вас теперь переменная цикла называется "Проверка всех бутылок в ящике"?
S>>2. Зачем вообще имя этому циклу?
S>>3. Вы написали пустой цикл. Это намеренное решение — дать имя фрагменту кода, который ничего не делает?
B>Не фрагменту кода, а объекту класса ForEach. И попрошу заметить синтаксис общий.
Сосредоточьтесь. Вы не отвечаете на мои вопросы.

S>>Программа соответствует некой модели, которая в свою очередь очень опосредованно связана с предметной областью.
B>Не буду спорить. Так как ты сформулировал даже правильней. В каких терминах хочешь получать информацию, так и пиши. Кроме как от написанного информацию брать неоткуда.
Это заблуждение. Есть ещё масса источников.

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

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

S>>>Какому компилятору это важно?
B>>Моему важно. У меня есть подстрочные, надстрочные значения и цветом можно выделять, например, комментарии.
S>У вас всё задом наперёд. В привычных средах не нужно выделять цветом комментарии. Выделение цветом делается автоматически, оно вторично по отношению к семантике комментариев. Я уже встречал на этом форуме авторов, которые пропагандировали "ручную" раскраску программ. Увы, реальных программистов убедить не удалось. Поясняю: в суровой реальности шансы на успех имеют решения, которые позволяют делать меньше.
S>Вот примеры матов в один ход:
S>- В моём языке я могу указывать, какую переменную положить в какой регистр!
S>- Точнее, ты должен указывать, какую переменную положить в какой регистр. Поэтому мы выбираем языки, в которых можно не указывать в какой регистр попадёт переменная, а компилятор достаточно умен, чтобы выбрать это за нас.

S>- В моей базе данных я могу указывать, какую физическую операцию нужно применять для джойна!
S>- Точнее, ты вынужден выбирать физическую реализацию для джойна. Поэтому мы выбираем СУБД, в которых можно не указывать план запроса, а движок достаточно умён, чтобы построить его за нас.

S>Понятно? Точно так же раскраски кода в фантастические цвета неинтересны. Как минимум до тех пор, пока не приведён убедительный пример использования, и обосновано, почему такой эффект нельзя получить в других подходах.
Раскраска делается автоматически транслятором, и это хорошо. А если нет требования уникальности на имена, то может понадобится для уточнения класса. Причем сам транслятор попросит уточнить. Примеры детские. Уже 20 лет как обсосаны.

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

B>>Правильно. Может быть очень много.
S>А зачем?

А анализ очень даже необходим не только для текста. Для анализа электрических цепей, да и мало ли чего еще. Просто средств для этого анализа нет. А у меня есть.

B>>У меня на одном. Хотя не могу быть специалистом во всех областях, но уверен что все можно конвертировать в классы-объекты.
S>Я понимаю, что вы заставляете всех писать на одном языке. Результат конверсии "всего" в классы-объекты вам уже приводили — XML. Нет такого документа, который нельзя было бы засунуть в XML. Это не означает, что XML способен заменить всё что угодно.

S>>>Прочитал я события. И что? Откуда возьмется экономия? И, главное, по сравнению с чем?
B>>Прочитай тогда правила группирования. Я думаю что ты поймешь.
S>Прочитал. Я тупой — объясните мне.
Я напишу статью. Вернее уже пишу. Кстати, можешь помочь? Нифига не въеду как заголовки и стиль скопировать. Написано Alt+[номер]. У меня ничего не изменяется. Пробовал писать?

B>>>>Потому как у меня сообщений нет.
S>>>Вы смысл слова "сообщение" в определении Алана Кея понимаете? Или вы опять подразумеваете под "сообщением" что-то своё, не то, что Алан Кей?
B>>Да согласен я с Аланом Кейем.
B>>Объект — базовая единица объектно-ориентированной системы.
B>>Объекты могут обладать состоянием.
B>>Посылка сообщения — единственный способ обмена информацией между объектами.
Ну, назови сообщениями события. Буду рад если полегчает. Сколько можно об одном и том же. Так как реализовано в смолтоке там действительно слово сообщения больше подходит. У меня события. И операции это операции. а+b это операция. Не считаю что логично считать это сообщением. Причем кто кому сообщает? Ну, не сотвори себе кумира. Если не принимаешь мой подход, имеешь право. Но не агитируй за смолток. Концепция мне нравится. Реализация нет.

B>> Что ж теперь уже ничего другого сказать нельзя? Ничего против его понимания сообщений не имею. Просто считаю что он сам бы согласился с тем, что механизм событий больше подходит.
S>Для чего он больше подходит?
S>Ок, вижу, понимание не налаживается. У вас вызовы методов есть? Есть. Это — частный случай общего понятия "посылка сообщения". Значит, само понятие посылки сообщения (отличное от вашей концепции событий) в языке уже есть.
Ну, и зачем понятное, и естественное "вызов метода" считать "посылкой сообщения"? Ради чего это нагромождение понятий? Только не вздумай отвечать Это риторический вопрос.

B>>А насчет состояний обрати внимание
B>>Объекты МОГУТ обладать состоянием. Могут, а не обязаны. Кстати, состояния инструкции таки меняют.
S>Ну вот я уже в четвёртый раз спрашиваю: где изменения состояния у инструкций? Сосредоточьтесь.
А по твоему объект for выполняет цикл и не меняет своего состояния? Могу еще привести объект If. Любой объект у меня выполняясь может изменить свойство Result. Т.е. выполниться успешно или не успешно. Оператор If у меня без секции Else. Для выполнения секции Else предназначен оператор Select. Так вот состояние оператора Select изменяется если выполнится один из вложеных в него операторов If. Если ни один из вложеных If-ов не выполнится, то выполняется секция (объект) Else если она есть.

B>>>>Да запросто
B>>>>ForEach "Проверка всех бутылок в ящике" In Ящик {}
S>>>1. Я правильно понимаю, что у вас теперь переменная цикла называется "Проверка всех бутылок в ящике"?
S>>>2. Зачем вообще имя этому циклу?
S>>>3. Вы написали пустой цикл. Это намеренное решение — дать имя фрагменту кода, который ничего не делает?
B>>Не фрагменту кода, а объекту класса ForEach. И попрошу заметить синтаксис общий.
S>Сосредоточьтесь. Вы не отвечаете на мои вопросы.
1. "Проверка всех бутылок в ящике" это не переменная, а имя объекта класса ForEach.
2. Имя для того что бы использовать при анализе уже готовой программы, для вывода сообщений, для указания этого имени при выходе из цикла оператором Exit.
3. Заполни тело цикла по своему разумению. Для примера это не важно.

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

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


B>Моему важно. У меня есть подстрочные, надстрочные значения и цветом можно выделять, например, комментарии.
B>И правила описания грамматик у меня свои. Ориентированы на ООП. В понятия можно включать предикаты. Потому можно проверять и наличие и значения свойств объекта. Буква- частный случай объектов.

Система контроля версий для хранения столь экзотических исходников тоже есть? Как будет выглядеть резолвинг конфликтов в этом разноцветном зоопарке, мне сложно себе представить. А ведь это только один нюанс, хоть и очень необходимый: без поддержки VCS язык мертв без вариантов.

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

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


B>>Моему важно. У меня есть подстрочные, надстрочные значения и цветом можно выделять, например, комментарии.
B>>И правила описания грамматик у меня свои. Ориентированы на ООП. В понятия можно включать предикаты. Потому можно проверять и наличие и значения свойств объекта. Буква- частный случай объектов.

E__>Система контроля версий для хранения столь экзотических исходников тоже есть? Как будет выглядеть резолвинг конфликтов в этом разноцветном зоопарке, мне сложно себе представить. А ведь это только один нюанс, хоть и очень необходимый: без поддержки VCS язык мертв без вариантов.
Есть, есть.. И даже есть конвертация из одной версии в другую.

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

E__>>Система контроля версий для хранения столь экзотических исходников тоже есть? Как будет выглядеть резолвинг конфликтов в этом разноцветном зоопарке, мне сложно себе представить. А ведь это только один нюанс, хоть и очень необходимый: без поддержки VCS язык мертв без вариантов.
B>Есть, есть.. И даже есть конвертация из одной версии в другую.

Вот на нее я бы посмотрел.

Здравствуйте, batu, Вы писали:
B>Раскраска делается автоматически транслятором, и это хорошо. А если нет требования уникальности на имена, то может понадобится для уточнения класса. Причем сам транслятор попросит уточнить. Примеры детские. Уже 20 лет как обсосаны.
Можно ссылку? Я не успеваю за полётом мысли. Если раскраска делается автоматически "транслятором", то цвет символа не является его свойством. Если раскраска выполняется человеком, то непонятно зачем.
За применение раскраски как способа различать одноимённые идентификаторы сразу же надо бить по рукам логарифмической линейкой. Потому как после печати на стандартном лазерном принтере смысл будет безнадёжно утерян.

B>А анализ очень даже необходим не только для текста. Для анализа электрических цепей, да и мало ли чего еще. Просто средств для этого анализа нет. А у меня есть.
Средства для анализа электрических цепей есть в программах по анализу электрических цепей. Есть какая-то надежда построить на основе LADA сколько-нибудь значимого конкурента какому-нибудь P-CAD?

S>>>>Прочитал я события. И что? Откуда возьмется экономия? И, главное, по сравнению с чем?
B>>>Прочитай тогда правила группирования. Я думаю что ты поймешь.
S>>Прочитал. Я тупой — объясните мне.
B>Я напишу статью. Вернее уже пишу. Кстати, можешь помочь? Нифига не въеду как заголовки и стиль скопировать. Написано Alt+[номер]. У меня ничего не изменяется. Пробовал писать?
Вы про это

Автор(ы): Брусенцев Виталий, Чистяков Владислав Юрьевич
Дата: 22.06.2011
Статья описывает шаблон для Microsoft Word предназначенный для верстки статей и преобразования их в формат RSDN ML. В статье рассматриваются вопросы использования шаблона.

? Тогда — да, пробовал.

B>Ну, назови сообщениями события. Буду рад если полегчает. Сколько можно об одном и том же.
Я не буду называть ваши события сообщениями. В терминах smalltalk сообщение — это, к примеру, Fire. А ваше "событие" — это полноценный объект, точно такой же, как и любой другой. Он никакого отношения к языку как таковому не имеет — его можно изобразить хоть на C#, хоть на Smalltalk.

B>Так как реализовано в смолтоке там действительно слово сообщения больше подходит. У меня события. И операции это операции. а+b это операция. Не считаю что логично считать это сообщением. Причем кто кому сообщает? Ну, не сотвори себе кумира.
Правильно. Поэтому a и b — это не объекты. И точно также и инструкции: у них нету состояния, нет обмена сообщениями. Это совершенно обычные структуры.

B>Если не принимаешь мой подход, имеешь право. Но не агитируй за смолток. Концепция мне нравится. Реализация нет.
Я не агитирую за smalltalk. Я агитирую за называние вещей привычными именами. И критический анализ действительности.

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

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

B>Могу еще привести объект If. Любой объект у меня выполняясь может изменить свойство Result. Т.е. выполниться успешно или не успешно.
А свойство Result — оно кому принадлежит? Объекту If? Или всей программе?

B>Оператор If у меня без секции Else. Для выполнения секции Else предназначен оператор Select. Так вот состояние оператора Select изменяется если выполнится один из вложеных в него операторов If. Если ни один из вложеных If-ов не выполнится, то выполняется секция (объект) Else если она есть.
Что именно вы называете "состоянием" оператора Select? Каково оно до того, как выполнится хоть один из вложенных в него операторов If? Каким оно станет после этого? Чем отличается Select, который ни разу не выполнялся, от Select, в котором сработала секция Else?
Что значит "выполнить объект" в вашей терминологии?

S>>Сосредоточьтесь. Вы не отвечаете на мои вопросы.
B>1. "Проверка всех бутылок в ящике" это не переменная, а имя объекта класса ForEach.
B>2. Имя для того что бы использовать при анализе уже готовой программы, для вывода сообщений, для указания этого имени при выходе из цикла оператором Exit.
Что такое "анализ уже готовой программы"?
Какие сообщения вы собрались выводить?
Про выход именованным exit я понял. Уже прогресс.
B>3. Заполни тело цикла по своему разумению. Для примера это не важно.
Искусственные примеры искажают результат. Они могут казаться осмысленными, пока не начнёшь писать реальную программу.

S>>Это заблуждение. Есть ещё масса источников.
B>Вот тут подробнее. Т.е. можно получить информацию от не написанного? Например.
Например, есть некоторое описание модели предметной области, которое связывает её с предметной областью. Либо информация вообще не нужна.
Ну вот к примеру есть у вас простая предметная область — какая-нибудь оплата электроэнергии через интернет. В этой предметной области есть понятия Счёт Плательщика, Плательщик, Показания Счётчика, Пеня, Платёж.
В программе, которая делает эту работу, будут объекты сотен классов, которые не имеют никакого отношения к предметной области. Их имена не нужно показывать ни в каких сообщениях — какой прок с них плательщику? Его вообще не интересует, что для показа сообщения используется какой-нибудь alertBox.
Разработчику, конечно, может быть интересно, где именно вычисляется значение пени на основе показаний и платежей. Но для этого вовсе не надо приписывать какие-то имена конкретным инструкциям, а тем более держать их в памяти сервера в процессе исполнения. Вполне достаточно иметь документацию по исходному коду, которую можно генерировать автоматически по технологиям, имеющим промышленную реализацию как минимум с 1993 года.

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

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

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

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

V>Да, входное текстовое представление разбирается и хранится в виде структур в некоей "базе знаний", по которой затем работает Пролог-машина.

И WAM не существует?

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

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

E__>>>Система контроля версий для хранения столь экзотических исходников тоже есть? Как будет выглядеть резолвинг конфликтов в этом разноцветном зоопарке, мне сложно себе представить. А ведь это только один нюанс, хоть и очень необходимый: без поддержки VCS язык мертв без вариантов.
B>>Есть, есть.. И даже есть конвертация из одной версии в другую.

E__>Вот на нее я бы посмотрел.
Код скинуть или рассказать?

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

S>Здравствуйте, batu, Вы писали:
B>>Раскраска делается автоматически транслятором, и это хорошо. А если нет требования уникальности на имена, то может понадобится для уточнения класса. Причем сам транслятор попросит уточнить. Примеры детские. Уже 20 лет как обсосаны.
S>Можно ссылку? Я не успеваю за полётом мысли. Если раскраска делается автоматически "транслятором", то цвет символа не является его свойством. Если раскраска выполняется человеком, то непонятно зачем.
S>За применение раскраски как способа различать одноимённые идентификаторы сразу же надо бить по рукам логарифмической линейкой. Потому как после печати на стандартном лазерном принтере смысл будет безнадёжно утерян.

B>>А анализ очень даже необходим не только для текста. Для анализа электрических цепей, да и мало ли чего еще. Просто средств для этого анализа нет. А у меня есть.
S>Средства для анализа электрических цепей есть в программах по анализу электрических цепей. Есть какая-то надежда построить на основе LADA сколько-нибудь значимого конкурента какому-нибудь P-CAD?

S>>>>>Прочитал я события. И что? Откуда возьмется экономия? И, главное, по сравнению с чем?
B>>>>Прочитай тогда правила группирования. Я думаю что ты поймешь.
S>>>Прочитал. Я тупой — объясните мне.
B>>Я напишу статью. Вернее уже пишу. Кстати, можешь помочь? Нифига не въеду как заголовки и стиль скопировать. Написано Alt+[номер]. У меня ничего не изменяется. Пробовал писать?
S>Вы про это

Автор(ы): Брусенцев Виталий, Чистяков Владислав Юрьевич
Дата: 22.06.2011
Статья описывает шаблон для Microsoft Word предназначенный для верстки статей и преобразования их в формат RSDN ML. В статье рассматриваются вопросы использования шаблона.

? Тогда — да, пробовал.

B>>Ну, назови сообщениями события. Буду рад если полегчает. Сколько можно об одном и том же.
S>Я не буду называть ваши события сообщениями. В терминах smalltalk сообщение — это, к примеру, Fire. А ваше "событие" — это полноценный объект, точно такой же, как и любой другой. Он никакого отношения к языку как таковому не имеет — его можно изобразить хоть на C#, хоть на Smalltalk.

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

B>>Если не принимаешь мой подход, имеешь право. Но не агитируй за смолток. Концепция мне нравится. Реализация нет.
S>Я не агитирую за smalltalk. Я агитирую за называние вещей привычными именами. И критический анализ действительности.

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

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

B>>Могу еще привести объект If. Любой объект у меня выполняясь может изменить свойство Result. Т.е. выполниться успешно или не успешно.
S>А свойство Result — оно кому принадлежит? Объекту If? Или всей программе?

B>>Оператор If у меня без секции Else. Для выполнения секции Else предназначен оператор Select. Так вот состояние оператора Select изменяется если выполнится один из вложеных в него операторов If. Если ни один из вложеных If-ов не выполнится, то выполняется секция (объект) Else если она есть.
S>Что именно вы называете "состоянием" оператора Select? Каково оно до того, как выполнится хоть один из вложенных в него операторов If? Каким оно станет после этого? Чем отличается Select, который ни разу не выполнялся, от Select, в котором сработала секция Else?
S>Что значит "выполнить объект" в вашей терминологии?

S>>>Сосредоточьтесь. Вы не отвечаете на мои вопросы.
B>>1. "Проверка всех бутылок в ящике" это не переменная, а имя объекта класса ForEach.
B>>2. Имя для того что бы использовать при анализе уже готовой программы, для вывода сообщений, для указания этого имени при выходе из цикла оператором Exit.
S>Что такое "анализ уже готовой программы"?
S>Какие сообщения вы собрались выводить?
S>Про выход именованным exit я понял. Уже прогресс.
B>>3. Заполни тело цикла по своему разумению. Для примера это не важно.
S> Искусственные примеры искажают результат. Они могут казаться осмысленными, пока не начнёшь писать реальную программу.

S>>>Это заблуждение. Есть ещё масса источников.
B>>Вот тут подробнее. Т.е. можно получить информацию от не написанного? Например.
S>Например, есть некоторое описание модели предметной области, которое связывает её с предметной областью. Либо информация вообще не нужна.
S>Ну вот к примеру есть у вас простая предметная область — какая-нибудь оплата электроэнергии через интернет. В этой предметной области есть понятия Счёт Плательщика, Плательщик, Показания Счётчика, Пеня, Платёж.
S>В программе, которая делает эту работу, будут объекты сотен классов, которые не имеют никакого отношения к предметной области. Их имена не нужно показывать ни в каких сообщениях — какой прок с них плательщику? Его вообще не интересует, что для показа сообщения используется какой-нибудь alertBox.
S>Разработчику, конечно, может быть интересно, где именно вычисляется значение пени на основе показаний и платежей. Но для этого вовсе не надо приписывать какие-то имена конкретным инструкциям, а тем более держать их в памяти сервера в процессе исполнения. Вполне достаточно иметь документацию по исходному коду, которую можно генерировать автоматически по технологиям, имеющим промышленную реализацию как минимум с 1993 года.
Я только из гостей..Благодарен за терпение..Но сейчас отвечать не в состоянии.. Давай завтра. Серьезно благодарен за внимание и что так раздалбываешь..Спасибо..Но до завтра..

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

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

[покоцано]

B>Я только из гостей..Благодарен за терпение..Но сейчас отвечать не в состоянии.. Давай завтра. Серьезно благодарен за внимание и что так раздалбываешь..Спасибо..Но до завтра..

Вам даже правила форума, на котором уже настрочили больше 4 сотен постов написали, лень прочитать?
BTW довольно странно видеть столь нечёткую "работу" с терминами и формулировками у математика (если юзеринфа соответствует действительности)

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


E__>>>>Система контроля версий для хранения столь экзотических исходников тоже есть? Как будет выглядеть резолвинг конфликтов в этом разноцветном зоопарке, мне сложно себе представить. А ведь это только один нюанс, хоть и очень необходимый: без поддержки VCS язык мертв без вариантов.
B>>>Есть, есть.. И даже есть конвертация из одной версии в другую.

E__>>Вот на нее я бы посмотрел.
B>Код скинуть или рассказать?

Меня устроит скриншот окна разрешения конфликтов для сложного случая. Код это хорошо, но под линух же версии нет, как я понимаю?

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


B>Я только из гостей..Благодарен за терпение..Но сейчас отвечать не в состоянии.. Давай завтра. Серьезно благодарен за внимание и что так раздалбываешь..Спасибо..Но до завтра..

Просьба не оверквотить так жестоко. Из гостей — понятно, с кем не бывает, но уважайте собеседников.

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


V>>Да, входное текстовое представление разбирается и хранится в виде структур в некоей "базе знаний", по которой затем работает Пролог-машина.

К>И WAM не существует?

Ну и? Ты спецификации смотрел? Эта абстрактная машина оперирует довольно высокоуровневыми структурами данных.