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

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


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

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

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

Покажи мне какие такие "высокоуровневые структуры", или байткод WAM это высокоуровневая структура данных, включая "элементы данных" allocate, get_nil и т.д.?
Меня несколько смущает ваша терминология.

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


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

Позволю себе не согласиться. Аспектная парадигма — это способ декомпозиции, как раз основанный на возможности включения сквозного "инородного кода", аспектов то бишь, во многие точки программы. Для императивного языка этими точками включения являются вызовы ф-ий/методов, для его языка — события.

Вообще, язык Лада, насколько я понял, стоит рассматривать как логический, с императивными процедурами, запускаемыми вычислителем, который, в свою очередь, работает по графу событий. Наворот весьма интересный, и лишь узкий опыт VB не позволяет автору объяснить суть происходящего.


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

Это дуальность библиотеки и среды исполнения. Как в дотнете многие типы определены вроде бы по-обычному в библиотеке, но среда исполнения их "знает в лицо". Насколько я понял, у него Event — это часть инфраструктуры. Когда и как вызывать события решается не само по себе, как в дотнете, например, а его виртуальной машиной-вычислителем. Группировка событий, логические операции над событиями — из той же области. Сами по себе, в классической реактивной программе не может быть никаких логических операций над событиями, ибо события происходят асинхронно, либо последовательно. Если же всем этим занимается некий вычислитель, то у него вполне может быть некий цикл вычислений, в рамках которых уже возможны логические операции над событиями.

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

Есть подозрение, что вся система однопоточная, с кооперативной многозадачностью. То бишь, вычислитель работает постоянно и генерирует события, вызывая подписчиков. Поэтому, сколько бы таймеров не было, остальной код тоже будет работать, просто события таймера будут проверяться реже.

S>Кстати, в контексте какого потока будет выполнен код Event, когда придёт время срабатывать?

В контексте того самого. Да, насчет эффективности там пока большое белое пятно. Хотелось бы взглянуть на исходники библиотеки ввода-вывода, а то есть кое-какие обоснованные подозрения...

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

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

Identity забыл.

Здравствуйте, 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 не объекты..У меня слов нет..

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

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

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

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

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 года.
Из твоих статей я понял что ты занимался базами данных. Тогда должен понимать, что дублирование данных непременно приводит к потере доверия к ней. Из-за того что данные рано или поздно начнут отличаться. Правильней их держать в одном месте. Кстати, это одна из причин трудностей с созданием электронного документооборота. Данные для анализа должны находится внутри объекта, а не в прикрепленных структурах как делается сейчас. Так со временем накапливаются различия между документом и прикрепленной к нему структурой данных.

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

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


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

E__>Просьба не оверквотить так жестоко. Из гостей — понятно, с кем не бывает, но уважайте собеседников.
Видимо я по другому воспитан. Считаю что лучше ответить и объясниться, чем молчать, вызывая недоумение.

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

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

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


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

E__>>Просьба не оверквотить так жестоко. Из гостей — понятно, с кем не бывает, но уважайте собеседников.
B>Видимо я по другому воспитан. Считаю что лучше ответить и объясниться, чем молчать, вызывая недоумение.

Видимо, ответить и не оверквотить — такой вариант даже не рассматривался?
Или тут мы имеем опять непонимание терминов и, как следствие, пункта 3 правил форума?
Hint: оверквотить != ответить.

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

B>Стандарты такая вещь..меняется..
На перспективу работаете? Или очень хочется ограничить рынок языка исключительно владельцами цветных принтеров, да ещё и с абсолютным цветоощущением?

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


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

S>>Правильно. Поэтому a и b — это не объекты. И точно также и инструкции: у них нету состояния, нет обмена сообщениями. Это совершенно обычные структуры.
B>Если а и b не объекты..У меня слов нет..
К примеру, целые числа не ведут себя как объекты. Поэтому реализация их через объекты (как, скажем, в том же Smalltalk) является надуманной.

B>Свои методы.. Вполне возможно. А вот вызывать чужие.. Надо подумать.
Конечно надо.

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

B>Я думаю на этот вопрос и сам можешь дать ответ. Малость подумавши.
Я — не могу. Я не понимаю идею инструкций, которые сами себя выполняют. У вас получается всё наоборот: виртуальная машина stateless, а инструкции stateful.
Я не понимаю, что изменяется в инструкции I = I + 1 при её выполнении. В классике меняется состояние машины: значение, хранящееся в переменной с именем "I". Инструкция остаётся точно такой же. Ей не нужен никакой Result — доступа к нему всё равно никто не получит.

S>>Что значит "выполнить объект" в вашей терминологии?
B>Объект поступивший на вход виртуальной машины и там обработаный.
А, то есть объект "for" не имеет шанса превратиться в обычный исполняемый код на x86? Ему всю жизнь придётся быть "объектом", и поступать на вход виртуальной машины для того, чтобы сделать хоть что-то полезное. Ага, про эффективность придётся забыть навсегда.

S>>Про выход именованным exit я понял. Уже прогресс.
B>>>3. Заполни тело цикла по своему разумению. Для примера это не важно.
S>> Искусственные примеры искажают результат. Они могут казаться осмысленными, пока не начнёшь писать реальную программу.

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

B>Из твоих статей я понял что ты занимался базами данных. Тогда должен понимать, что дублирование данных непременно приводит к потере доверия к ней.
Я много чем занимался. Откуда возьмется дублирование в JavaDoc?

B>Из-за того что данные рано или поздно начнут отличаться. Правильней их держать в одном месте. Кстати, это одна из причин трудностей с созданием электронного документооборота. Данные для анализа должны находится внутри объекта, а не в прикрепленных структурах как делается сейчас. Так со временем накапливаются различия между документом и прикрепленной к нему структурой данных.
Я не знаю, что вы называете "электронным документооборотом". В том, что понимаю под этим я, никаких особенных трудностей нет. Кроме того, эта область никакого отношения к программированию не имеет.

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


V>Есть подозрение, что вся система однопоточная, с кооперативной многозадачностью. То бишь, вычислитель работает постоянно и генерирует события, вызывая подписчиков. Поэтому, сколько бы таймеров не было, остальной код тоже будет работать, просто события таймера будут проверяться реже.

Ну, тогда все совсем печально. Я понимаю однопоточность для какого-нибудь жабаскрипта в браузере, но не для полноценного же языка.

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

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


V>>Есть подозрение, что вся система однопоточная, с кооперативной многозадачностью. То бишь, вычислитель работает постоянно и генерирует события, вызывая подписчиков. Поэтому, сколько бы таймеров не было, остальной код тоже будет работать, просто события таймера будут проверяться реже.

E__>Ну, тогда все совсем печально. Я понимаю однопоточность для какого-нибудь жабаскрипта в браузере, но не для полноценного же языка.

Эрланг — неполноценный? nginx (пусть и не язык) — неполноценный веб-сервер?
На том же жабаскрипте есть node.js

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

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

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

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

S>>>Правильно. Поэтому a и b — это не объекты. И точно также и инструкции: у них нету состояния, нет обмена сообщениями. Это совершенно обычные структуры.
B>>Если а и b не объекты..У меня слов нет..
S> К примеру, целые числа не ведут себя как объекты. Поэтому реализация их через объекты (как, скажем, в том же Smalltalk) является надуманной.
Прочитай еще раз у меня про объекты. Есть объекты-классы, объекты-типы (или объекты-значения) и объекты-инструкции. Это разные вещи.

B>>Свои методы.. Вполне возможно. А вот вызывать чужие.. Надо подумать.
S>Конечно надо. Подумаю.

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

B>>Я думаю на этот вопрос и сам можешь дать ответ. Малость подумавши.
S>Я — не могу. Я не понимаю идею инструкций, которые сами себя выполняют. У вас получается всё наоборот: виртуальная машина stateless, а инструкции stateful.
S>Я не понимаю, что изменяется в инструкции I = I + 1 при её выполнении. В классике меняется состояние машины: значение, хранящееся в переменной с именем "I". Инструкция остаётся точно такой же. Ей не нужен никакой Result — доступа к нему всё равно никто не получит.
В вашем примере две инструкции. Сложения и присвоения.

S>>>Что значит "выполнить объект" в вашей терминологии?
B>>Объект поступивший на вход виртуальной машины и там обработаный.
S>А, то есть объект "for" не имеет шанса превратиться в обычный исполняемый код на x86?
Очень даже превращается. А то как же. Зачем вы спрашиваете очевидные вещи? Стеб?
Ему всю жизнь придётся быть "объектом", и поступать на вход виртуальной машины для того, чтобы сделать хоть что-то полезное. Ага, про эффективность придётся забыть навсегда.
Да. Эффективность будет ниже. Я уже писал об этом. Но причина не в реализации объектов, Здесь разницы нет, а в проверке на события.


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

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

B>>Из-за того что данные рано или поздно начнут отличаться. Правильней их держать в одном месте. Кстати, это одна из причин трудностей с созданием электронного документооборота. Данные для анализа должны находится внутри объекта, а не в прикрепленных структурах как делается сейчас. Так со временем накапливаются различия между документом и прикрепленной к нему структурой данных.
S>Я не знаю, что вы называете "электронным документооборотом". В том, что понимаю под этим я, никаких особенных трудностей нет. Кроме того, эта область никакого отношения к программированию не имеет.
Не имеет так не имеет. Вопрос снят.

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

B>>Я думаю на этот вопрос и сам можешь дать ответ. Малость подумавши.
S>Я — не могу. Я не понимаю идею инструкций, которые сами себя выполняют.

А как же Форт?

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



V>>>Есть подозрение, что вся система однопоточная, с кооперативной многозадачностью. То бишь, вычислитель работает постоянно и генерирует события, вызывая подписчиков. Поэтому, сколько бы таймеров не было, остальной код тоже будет работать, просто события таймера будут проверяться реже.

E__>>Ну, тогда все совсем печально. Я понимаю однопоточность для какого-нибудь жабаскрипта в браузере, но не для полноценного же языка.

К>Эрланг — неполноценный? nginx (пусть и не язык) — неполноценный веб-сервер?

Автор позиционирует свой язык для всего-всего-всего. Так вот есть куча задач, принципиально нерашаемых без использования многопоточности.

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

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



V>>>>Есть подозрение, что вся система однопоточная, с кооперативной многозадачностью. То бишь, вычислитель работает постоянно и генерирует события, вызывая подписчиков. Поэтому, сколько бы таймеров не было, остальной код тоже будет работать, просто события таймера будут проверяться реже.

E__>>>Ну, тогда все совсем печально. Я понимаю однопоточность для какого-нибудь жабаскрипта в браузере, но не для полноценного же языка.

К>>Эрланг — неполноценный? nginx (пусть и не язык) — неполноценный веб-сервер?

E__>Автор позиционирует свой язык для всего-всего-всего. Так вот есть куча задач, принципиально нерашаемых без использования многопоточности.

Эрланг вполне универсальный язык (но имеет вполне внятное позиционирование, конечно), а про кучу задач хочется поподробнее, если можно.

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

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

B>>>Я думаю на этот вопрос и сам можешь дать ответ. Малость подумавши.
S>>Я — не могу. Я не понимаю идею инструкций, которые сами себя выполняют.

V>А как же Форт?

А каким образом там инструкции сами себя выполняют? Процессор им тоже не нужен?

B>Ну, и зачем понятное, и естественное "вызов метода" считать "посылкой сообщения"? Ради чего это нагромождение понятий? Только не вздумай отвечать Это риторический вопрос.
Кстати,был как-то спор на тему "Посылка сообщения против вызова методов".
Сообщения обрабатываются одним заведомо известным методом(типа WndProc в WinApi).
Преимущество,что неопознанные сообщения просто проскакивают сквозь case, не порождая никаких исключений,а вызов несуществующего метода — да.

S>>>>Правильно. Поэтому a и b — это не объекты. И точно также и инструкции: у них нету состояния, нет обмена сообщениями. Это совершенно обычные структуры.
B>>>Если а и b не объекты..У меня слов нет..
S>> К примеру, целые числа не ведут себя как объекты. Поэтому реализация их через объекты (как, скажем, в том же Smalltalk) является надуманной.
B>Прочитай еще раз у меня про объекты. Есть объекты-классы, объекты-типы (или объекты-значения) и объекты-инструкции. Это разные вещи.

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

Уберите слово "объект" от инструкций и сразу всем станет чуточку проще понимать о чём вы говорите.

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

B>На перспективу.
Ну, тогда подождём.

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

S>> К примеру, целые числа не ведут себя как объекты. Поэтому реализация их через объекты (как, скажем, в том же Smalltalk) является надуманной.
B>Прочитай еще раз у меня про объекты. Есть объекты-классы, объекты-типы (или объекты-значения) и объекты-инструкции. Это разные вещи.
В чём различие? В чём общность? Меня настораживает эквивалентность объектов-типов и объектов-значнений. Она говорит либо о том, что вы не различаете понятия "тип" и "значение", либо о том, что вы непоследовательно пользуетесь собственной терминологией.

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

S>>Я не понимаю, что изменяется в инструкции I = I + 1 при её выполнении. В классике меняется состояние машины: значение, хранящееся в переменной с именем "I". Инструкция остаётся точно такой же. Ей не нужен никакой Result — доступа к нему всё равно никто не получит.
B>В вашем примере две инструкции. Сложения и присвоения.
Или три. Доступа к значению, сложения, и присваивания. Или пять — доступа к значению, приведения типа, сложения, приведения типа, присваивания.
Ни у одной из них нет никакого изменяемого состояния.

S>>А, то есть объект "for" не имеет шанса превратиться в обычный исполняемый код на x86?
B>Очень даже превращается. А то как же. Зачем вы спрашиваете очевидные вещи? Стеб?
Нет. Ничего очевидного тут нету. Ну вот к примеру — как же он превратится в исполняемый код, если без виртуальной машины он всё равно не может выполниться?

B>Да. Эффективность будет ниже. Я уже писал об этом. Но причина не в реализации объектов, Здесь разницы нет, а в проверке на события.
А что, нельзя как-то оптимизировать вот эту "проверку на события"? По идее, это должно быть очень легко — из миллионов происходящих событий интерес вызывают лишь немногие.
Реализация "объектов", конечно же, будет оказывать разительное влияние. Например, если цикл for не имеет никакого "состояния", которое он обязан менять в процессе исполнения, компилятор может его развернуть, или вовсе устранить. К примеру, тут выше пробегал код, где в цикле происходит одно и то же присваивание. Современный компилятор с промышленного языка программирования перенесёт присваивание за цикл, а сам цикл устранит как избыточный.
Ваш компилятор ничего подобного сделать не сможет — потому, что у for есть какой-то Result, который нужно менять при исполнении, даже если внутри цикла ничего не происходит.

Я уже пытался это объяснить несколько постингов назад, но не вижу понимания с вашей стороны. Возможно, это просто я никак не могу воспринять ваши идеи.

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

B>>Ну, и зачем понятное, и естественное "вызов метода" считать "посылкой сообщения"? Ради чего это нагромождение понятий? Только не вздумай отвечать Это риторический вопрос.
OV_>Кстати,был как-то спор на тему "Посылка сообщения против вызова методов".
OV_>Сообщения обрабатываются одним заведомо известным методом(типа WndProc в WinApi).
OV_>Преимущество,что неопознанные сообщения просто проскакивают сквозь case, не порождая никаких исключений,а вызов несуществующего метода — да.
И как вы считаете что лучше?

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

S>>>>>Правильно. Поэтому a и b — это не объекты. И точно также и инструкции: у них нету состояния, нет обмена сообщениями. Это совершенно обычные структуры.
B>>>>Если а и b не объекты..У меня слов нет..
S>>> К примеру, целые числа не ведут себя как объекты. Поэтому реализация их через объекты (как, скажем, в том же Smalltalk) является надуманной.
B>>Прочитай еще раз у меня про объекты. Есть объекты-классы, объекты-типы (или объекты-значения) и объекты-инструкции. Это разные вещи.

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

T>Уберите слово "объект" от инструкций и сразу всем станет чуточку проще понимать о чём вы говорите.
Не могу. Инструкции так же имеют свойства, так же создаются на основе класса. По тем же правилам как и объекты и типы. И можно создать новый класс инструкций. Имеют такой же формат. Единственно правильным придумать какое-то новое слово. А то объект-объект, действительно выглядит кракозяброй. Например,Z обозвать. Тогда логичней. Z-объект, Z-значение, Z-инструкция. Но, на такое придумывание у меня наглости не хватило.

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

V>А как же Форт?
Также, как и везде — есть форт-машина, которая исполняет инструкции. Архитектура машины внятно описана, instruction set — тоже. Наличие шитого кода никак не опровергает instruction immutability.