Re[27]: А вот вам и новый язык. Зацените. Можно ругать. - Философия программирования

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

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

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

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

S>>>

К примеру, целые числа не ведут себя как объекты. Поэтому реализация их через объекты (как, скажем, в том же Smalltalk) является надуманной.
B>>Прочитай еще раз у меня про объекты. Есть объекты-классы, объекты-типы (или объекты-значения) и объекты-инструкции. Это разные вещи.
S>В чём различие? В чём общность? Меня настораживает эквивалентность объектов-типов и объектов-значнений. Она говорит либо о том, что вы не различаете понятия "тип" и "значение", либо о том, что вы непоследовательно пользуетесь собственной терминологией.
Логичней, конечно, "значения". "Тип" написал только потому, что z-значения (в предыдущем посте вместо объектов я буду ставить букву z) порождаются классом Type, z-объекты классо Class, а z-инструкции классом Instruction.
Разница между z-объектами и z-значениями, классическая. Значения сравниваются по значению свойств, а объекты по адресу. Объект (равный и одновременно) может быть только один, а значений (равных и одновременных) может быть много. Изменение свойств объекта не делает его другим, а изменение свойств значения делает значение другим. Кроме этих отличий z-значения имеют числовое или текстовое представление. Например, "10", "1 августа 1999г". Этот факт заставляет обратить внимание на, то что определение нового типа требует изменений для лексического анализатора. Потому как в тексте программы может оказаться значение нового типа и его необходимо опознать.

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

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

B>>В вашем примере две инструкции. Сложения и присвоения.
S>Или три. Доступа к значению, сложения, и присваивания. Или пять — доступа к значению, приведения типа, сложения, приведения типа, присваивания.
S>Ни у одной из них нет никакого изменяемого состояния.

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

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

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

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

B>>Ну, и зачем понятное, и естественное "вызов метода" считать "посылкой сообщения"? Ради чего это нагромождение понятий? Только не вздумай отвечать

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

Это зависит от представлений сообщений. Посмотри Axum, там есть message passing, но нет "неопознаных" сообщений.

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

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

B>Разница между z-объектами и z-значениями, классическая. Значения сравниваются по значению свойств, а объекты по адресу. Объект (равный и одновременно) может быть только один, а значений (равных и одновременных) может быть много. Изменение свойств объекта не делает его другим, а изменение свойств значения делает значение другим.
Отлично. Неплохое описание reference-семантики и value-семантики.
Хочу отметить, что значения лишены идентичности, фундаментального свойства объектов. Префикс z значениям, в общем-то, не нужен. Это самые обычные значения (экземпляры значимых типов), поведение которых нам хорошо известно по другим реализациям.

B>Кроме этих отличий z-значения имеют числовое или текстовое представление. Например, "10", "1 августа 1999г". Этот факт заставляет обратить внимание на, то что определение нового типа требует изменений для лексического анализатора. Потому как в тексте программы может оказаться значение нового типа и его необходимо опознать.
Это крайне неудобно — большинство современных промышленных языков (по крайней мере, начиная с C) умеют строить новые типы-значения безо всякого вмешательства в лексический анализатор. Зачем вы усложняете задачу на ровном месте?

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

S>>>>Я не понимаю, что изменяется в инструкции I = I + 1 при её выполнении. В классике меняется состояние машины: значение, хранящееся в переменной с именем "I". Инструкция остаётся точно такой же. Ей не нужен никакой Result — доступа к нему всё равно никто не получит.
B>Получит, получит. Если будет выполняться группа инструкций (смотрим выполнение группы), то виртуальная машина будет его анализировать.
А зачем виртуальной машине что-то анализировать? Она и так исполняет эту инструкцию, так что машине про инструкцию известно всё. Простой пример из реальной жизни: ассемблер x86. С операцией add не ассоциировано никакого result. Результаты операции попадут в регистр флагов.

S>>Или три. Доступа к значению, сложения, и присваивания. Или пять — доступа к значению, приведения типа, сложения, приведения типа, присваивания.
S>>Ни у одной из них нет никакого изменяемого состояния.

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

iter = subscribers.head;
while(iter != null)
{ 
  iter.current.Notify(oldValue, newValue);
  iter = iter.next;
}

Теперь представим себе, что у нас таких переменных — десять тысяч. А подписаны фактически мы только на одну.
Вот у нас есть фрагмент кода:

A += 1;
B += 1;

На изменения B никаких подписчиков нету. Значит, можно при компиляции весь цикл оповещения подписчиков устранить вовсе. Сразу выполнить присваивание и ехать дальше. Для первой и второй строчек получится разный код.
Для того, чтобы это работало, нужно иметь возможность перекомпилировать код после того, как изменится список подписчиков — ничего военного, в наш век джита. Это всё называется "спекулятивная оптимизация".

B>С оптимизацией да. Нужно будет чего-то придумывать.
А то. Без оптимизации невозможно получить сколь-нибудь приемлемую производительность даже для простых программ.
Я вам открою тайну: современные языки "в лоб" никто не исполняет. Разворачивают циклы, инлайнят вызовы, устраняют виртуальность, и очень много всего прочего. В режиме интерпретации JVM будет работать не в три раза медленнее, а на порядки.

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

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

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

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

B>>Кроме этих отличий z-значения имеют числовое или текстовое представление. Например, "10", "1 августа 1999г". Этот факт заставляет обратить внимание на, то что определение нового типа требует изменений для лексического анализатора. Потому как в тексте программы может оказаться значение нового типа и его необходимо опознать.
S>Это крайне неудобно — большинство современных промышленных языков (по крайней мере, начиная с C) умеют строить новые типы-значения безо всякого вмешательства в лексический анализатор. Зачем вы усложняете задачу на ровном месте?
Упрощаю.

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

S>>>>>Я не понимаю, что изменяется в инструкции I = I + 1 при её выполнении. В классике меняется состояние машины: значение, хранящееся в переменной с именем "I". Инструкция остаётся точно такой же. Ей не нужен никакой Result — доступа к нему всё равно никто не получит.
B>>Получит, получит. Если будет выполняться группа инструкций (смотрим выполнение группы), то виртуальная машина будет его анализировать.
S>А зачем виртуальной машине что-то анализировать? Она и так исполняет эту инструкцию, так что машине про инструкцию известно всё. Простой пример из реальной жизни: ассемблер x86. С операцией add не ассоциировано никакого result. Результаты операции попадут в регистр флагов.
Ну, так изменят состоянии машины

Кроме значения и флаги могут измениться.

S>>>Или три. Доступа к значению, сложения, и присваивания. Или пять — доступа к значению, приведения типа, сложения, приведения типа, присваивания.
S>>>Ни у одной из них нет никакого изменяемого состояния.
Спорный вопрос. А флаги?

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

S>

S>iter = subscribers.head;
S>while(iter != null)
S>{ 
S>  iter.current.Notify(oldValue, newValue);
S>  iter = iter.next;
S>}
S>

S>Теперь представим себе, что у нас таких переменных — десять тысяч. А подписаны фактически мы только на одну.
S>Вот у нас есть фрагмент кода:
S>

S>A += 1;
S>B += 1;
S>

S>На изменения B никаких подписчиков нету. Значит, можно при компиляции весь цикл оповещения подписчиков устранить вовсе. Сразу выполнить присваивание и ехать дальше. Для первой и второй строчек получится разный код.
S>Для того, чтобы это работало, нужно иметь возможность перекомпилировать код после того, как изменится список подписчиков — ничего военного, в наш век джита. Это всё называется "спекулятивная оптимизация".
Не думаю что так просто получится. Сама по себе подписка еще не означает что событие произойдет. Там еще проверку условия необходимо сделать. Гарантировать отсутствие необходимости "ловить" событие может только отсутствие процедуры обработки. Но, нет гарантии что далее в цепочке подписаных событий не будет события с процедурой.

B>>С оптимизацией да. Нужно будет чего-то придумывать.
S>А то. Без оптимизации невозможно получить сколь-нибудь приемлемую производительность даже для простых программ.
S>Я вам открою тайну: современные языки "в лоб" никто не исполняет. Разворачивают циклы, инлайнят вызовы, устраняют виртуальность, и очень много всего прочего. В режиме интерпретации JVM будет работать не в три раза медленнее, а на порядки.
Это не тайна. Еще и про распараллеливание напомни. И тем не менее...

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

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

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

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

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

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

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

B>Но там нет Condition.
Где нет Condition?

B>>>Кроме этих отличий z-значения имеют числовое или текстовое представление. Например, "10", "1 августа 1999г". Этот факт заставляет обратить внимание на, то что определение нового типа требует изменений для лексического анализатора. Потому как в тексте программы может оказаться значение нового типа и его необходимо опознать.
S>>Это крайне неудобно — большинство современных промышленных языков (по крайней мере, начиная с C) умеют строить новые типы-значения безо всякого вмешательства в лексический анализатор. Зачем вы усложняете задачу на ровном месте?
B>Упрощаю.
Не вижу упрощения. Структурные типы очень популярны в программировании. Ну вот простая проверка: сколько будет стоить ввести в ваш язык тип "комплексное число"?

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

S>>А зачем виртуальной машине что-то анализировать? Она и так исполняет эту инструкцию, так что машине про инструкцию известно всё. Простой пример из реальной жизни: ассемблер x86. С операцией add не ассоциировано никакого result. Результаты операции попадут в регистр флагов.
B>Ну, так изменят состоянии машины

Кроме значения и флаги могут измениться.
И? Я же говорю — изменяется машина. Инструкции — нет.

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

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

B>>>С оптимизацией да. Нужно будет чего-то придумывать.
S>>А то. Без оптимизации невозможно получить сколь-нибудь приемлемую производительность даже для простых программ.
S>>Я вам открою тайну: современные языки "в лоб" никто не исполняет. Разворачивают циклы, инлайнят вызовы, устраняют виртуальность, и очень много всего прочего. В режиме интерпретации JVM будет работать не в три раза медленнее, а на порядки.
B>Это не тайна. Еще и про распараллеливание напомни. И тем не менее...
Ну, для вас, похоже, тайна.

Распараллеливание к оптимизации имеет очень косвенное отношение — в том смысле, что нужно далеко не везде. Есть разные ниши; в системах массового обслуживания (все современные клиент-серверные архитектуры) многопоточность используется для одновременного выполнения последовательных алгоритмов. Распараллеливание нужно для случаев, когда у нас есть достаточно большая задача, чтобы время её обслуживания стало важным. А таких случаев немного; обычно достаточно обеспечить throughput — то есть количество задач, выполняемых в единицу времени. Вот тут как раз рулят классические алгоритмы оптимизации.

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

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

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

Так же как в Ладе, насколько я понял. Получают управление и что-то делают. Можно еще привести пример Лиспа и т.д.

К>Процессор им тоже не нужен?

Абсурдный вопрос.

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

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

B>>Но там нет Condition.
S>Где нет Condition?
Потерял нить.. Наверное, имелось в виду в сообщениях.
Обмен сообщениями более общее понятие, чем мои события и их можно смоделировать сетями Петри. Для моделирования событий можно определить более узкий класс сетей -подмножество сетей Петри. Я даже набросал определения этих сетей и кое-какие задачи на них. Преимущество этих сетей в том, что они проще и там легче решаются некоторые задачи. Типа недостижимых состояний, полноты, зацикливания.Хотя зацикливание, это обычно нормальная работа автомата.
Это так. Можно считать что не по теме.

S>Не вижу упрощения. Структурные типы очень популярны в программировании. Ну вот простая проверка: сколько будет стоить ввести в ваш язык тип "комплексное число"?
Формат и все что необходимо для лексического анализа определяется так.

Type Complex
 {
  Dim Float Real
  {"+"
    Dim Float UnReal
   "I"
  }0  ' 0-это подстрочное значение. Обозначающее, что находящееся в скобках может остутсвовать
 }

Конечно, надо определить операции. Но, это будет темой дальнейшего обсуждения.

S>Ничего. Постепенно туман в голове рассеется, лишнее отбросится, важное выкристаллизуется.
Для того и общаемся.

B>>Там еще проверку условия необходимо сделать. Гарантировать отсутствие необходимости "ловить" событие может только отсутствие процедуры обработки. Но, нет гарантии что далее в цепочке подписаных событий не будет события с процедурой.
S>Это место мне непонятно. Если нет обработчика исходного события, то нет и никакой "цепочки".
Есть. Событие C подписано к событию B, а событие B подписано на событие A. Событие B не имеет обработчика, а событие С — имеет.
При срабатывании события А, происходит событие B, но не нуждается в обработке, но сам факт события B вызывает проверку на событие C, а там уже есть обработчик.

S>>>Я вам открою тайну: современные языки "в лоб" никто не исполняет.
B>>Это не тайна. Еще и про распараллеливание напомни. И тем не менее...
S>Ну, для вас, похоже, тайна.
Поверь не тайна.

S>Распараллеливание к оптимизации имеет очень косвенное отношение — в том смысле, что нужно далеко не везде. Есть разные ниши; в системах массового обслуживания (все современные клиент-серверные архитектуры) многопоточность используется для одновременного выполнения последовательных алгоритмов. Распараллеливание нужно для случаев, когда у нас есть достаточно большая задача, чтобы время её обслуживания стало важным. А таких случаев немного; обычно достаточно обеспечить throughput — то есть количество задач, выполняемых в единицу времени. Вот тут как раз рулят классические алгоритмы оптимизации.
Позволь не согласиться насчет косвенного отношения. Я промолчу про многопроцессорные системы, но даже в одном процессоре могут выполняться несколько операций одновременно. Конвеейрная обработка. Предвычисление адреса перехода. И т.п. Компиляторы даже балуются тем, что переставляют команды местами.

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

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

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

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

V>Так же как в Ладе, насколько я понял. Получают управление и что-то делают. Можно еще привести пример Лиспа и т.д.

К>>Процессор им тоже не нужен?

V>Абсурдный вопрос.

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

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

B>Формат и все что необходимо для лексического анализа определяется так.
B>

B>Type Complex
B> {
B>  Dim Float Real
B>  {"+"
B>    Dim Float UnReal
B>   "I"
B>  }0  ' 0-это подстрочное значение. Обозначающее, что находящееся в скобках может остутсвовать
B> }
B>

B>Конечно, надо определить операции. Но, это будет темой дальнейшего обсуждения.

[занудность on]
Интересно, как может математик и не знать почему для комплексных чисел используется буква i?

(hint: речь про UnReal, в котором к том уже используется довольно странное обхождение с регистром...)
[занудность off]

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

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

B>>>Ну, и зачем понятное, и естественное "вызов метода" считать "посылкой сообщения"? Ради чего это нагромождение понятий? Только не вздумай отвечать

Это риторический вопрос.
OV_>>Кстати,был как-то спор на тему "Посылка сообщения против вызова методов".
OV_>>Сообщения обрабатываются одним заведомо известным методом(типа WndProc в WinApi).
OV_>>Преимущество,что неопознанные сообщения просто проскакивают сквозь case, не порождая никаких исключений,а вызов несуществующего метода — да.
B>И как вы считаете что лучше?
Не знаю,вроде бы уже все смешалось и нет особой разницы.
1.Скажем,в Delphi TObject — базовый класс для всех остальных,
TObject = class
...
procedure Dispatch(var Message); virtual;
procedure DefaultHandler(var Message); virtual;
...
end;
и далее
TForm = class(...)
...
procedure WMNCHitTest(var Message: TWMNCHitTest); message WM_NCHITTEST;
...
end;
Т.е. послать сообщение объекту здесь-вызвать метод Dispatch(),а обработчик сообщения будет либо назначенный,либо DefaultHandler.
2.Или,например такой код:
CLASS TOleAuto
...
ERROR HANDLER OnError()
...
ENDCLASS
METHOD OnError( uParam1, uParam2, uParam3, uParam4, uParam5, uParam6 ) CLASS TOleAuto
LOCAL cMsg := __GetMessage()
LOCAL uObj
IF LEFT( cMsg, 1 ) == '_'
::Set( SUBS( cMsg, 2 ), uParam1, uParam2, uParam3, uParam4, uParam5, uParam6 )
ELSE
uObj := ::Get( cMsg, uParam1, uParam2, uParam3, uParam4, uParam5, uParam6 )
ENDIF
RETURN uObj
Здесь вызов несуществующего метода перехватывается в обработчике OnError и трактуется как посылка сообщения,
где идентификатор типа сообщения уже не число, а строка — <Имя метода>.Ну и параметры соответственно.

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

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

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

B>>>>Ну, и зачем понятное, и естественное "вызов метода" считать "посылкой сообщения"? Ради чего это нагромождение понятий? Только не вздумай отвечать

Это риторический вопрос.
OV_>где идентификатор типа сообщения уже не число, а строка — <Имя метода>.Ну и параметры соответственно.
Мне хотелось бы верить в то, что мы здесь обсуждаем варианты с целью выяснить какой из подходов логичнее, перспективнее и какую из концепций признать более естественной. Сделать можно как угодно, и мы понимаем этот печальный факт. Обсуждаем, предлагаем!

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

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

К>[занудность on]
К>Интересно, как может математик и не знать почему для комплексных чисел используется буква i?

К>(hint: речь про UnReal, в котором к том уже используется довольно странное обхождение с регистром...)
К>[занудность off]
Клянусь, переключал регистр

Заметил при редактировании, но не проверил как отредактировалось...

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

B>>>Но там нет Condition.
S>>Где нет Condition?
B>Потерял нить.. Наверное, имелось в виду в сообщениях.
Мне было бы комфортнее, если бы вы общались со мной, а не с вымышленным оппонентом.
Благо на этом форуме все технические средства для этого есть.
Напомню контекст: мы говорим о встраивании событий в язык против построения их в библиотеке.
Пока что никаких внятных аргументов в пользу втаскивания событий на уровень языка я не увидел (что, конечно же, не означает, что их вовсе нет).

B>Это так. Можно считать что не по теме.
А, это интересно. Но это будет после того, как мы проясним элементарные вещи.

B>Формат и все что необходимо для лексического анализа определяется так.
B>

B>Type Complex
B> {
B>  Dim Float Real
B>  {"+"
B>    Dim Float UnReal
B>   "I"
B>  }0  ' 0-это подстрочное значение. Обозначающее, что находящееся в скобках может остутсвовать
B> }
B>

Непонятно. Что это будет означать? Как записываются комплексные числа в программе? Как обрабатываются конфликты разбора правил?

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

B>>>Там еще проверку условия необходимо сделать. Гарантировать отсутствие необходимости "ловить" событие может только отсутствие процедуры обработки. Но, нет гарантии что далее в цепочке подписаных событий не будет события с процедурой.
S>>Это место мне непонятно. Если нет обработчика исходного события, то нет и никакой "цепочки".
B>Есть. Событие C подписано к событию B, а событие B подписано на событие A. Событие B не имеет обработчика, а событие С — имеет.
B>При срабатывании события А, происходит событие B, но не нуждается в обработке, но сам факт события B вызывает проверку на событие C, а там уже есть обработчик.
Вы не понимаете. Я говорю о ситуации, когда событие A не имеет подписчиков. C и D могут сколько угодно подписываться друг на друга. Я же привёл вам пример, разжёванный почти что до ассемблерного кода.
Это аналог спекулятивных оптимизаций, выполняемых, к примеру, для инлайнинга виртуальных вызовов. Вам знакома эта техника?

B>Позволь не согласиться насчет косвенного отношения. Я промолчу про многопроцессорные системы, но даже в одном процессоре могут выполняться несколько операций одновременно. Конвеейрная обработка. Предвычисление адреса перехода. И т.п. Компиляторы даже балуются тем, что переставляют команды местами.
Поясняю ещё раз, медленно: возьмём, к примеру, многопроцессорную систему. На ней строится сервер, который реализует какую-нибудь простую вещь. Например, принимает на вход текстовую строку и превращает её в картинку PNG.
Допустим, на одном процессоре мы нашу строчку превращаем в картинку за 1000мс. Нужно ли упахиваться, распараллеливая алгоритм на 16 процессоров, которые нам доступны? Ответ зависит от того, что мы выиграем. Допустим, параллелизация дала бы нам возможность отрендерить картинку за 200мс (с учётом накладных расходов на межпроцессорное взаимодействие).
Что это означает с точки зрения системы массового обслуживания? Что мы умеем обрабатывать до 5 запросов в секунду.
При этом если бы мы не распараллеливали алгоритм, а тупо занимали бы один процессор, то обрабатывали бы 16 запросов в секунду. В самом-самом лучшем случае, если нам удалось построить идеально распараллеленный алгоритм без накладных расходов, то мы получили бы те же самые 16 картинок в секунду. Это математика — её не обманешь.
Именно так работают большинство современных веб-приложений. Потому что рулит throughput до тех пор, пока response time приемлемый. Если запрос обрабатывается один час, то пользователю малоинтересно, что одновременно с ним обрабатывается ещё 1000 запросов. Он предпочтёт чтобы его запрос обработался за 4 секунды, а остальные пусть потом обрабатываются.

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

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

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

S>Мне было бы комфортнее, если бы вы общались со мной, а не с вымышленным оппонентом.
S>Благо на этом форуме все технические средства для этого есть.
Даже не обольщайтесь! Во первых вы редкий собеседник по уровню общения, во вторых вы из новосибирска. А там живет моя сестра. Так что как оппонент вы просто великолепный и незабываемый.
S>Напомню контекст: мы говорим о встраивании событий в язык против построения их в библиотеке.
S>Пока что никаких внятных аргументов в пользу втаскивания событий на уровень языка я не увидел (что, конечно же, не означает, что их вовсе нет).
Нет аргументов. Вообще-то я предполагал наличие отдельного "диспечтера событий", но это вполне можно реализовать и в библиотеке.

B>>Это так. Можно считать что не по теме.
S>А, это интересно. Но это будет после того, как мы проясним элементарные вещи.
Угу.

B>>Формат и все что необходимо для лексического анализа определяется так.
B>>

B>>Type Complex
B>> {
B>>  Dim Float Real
B>>  {"+"
B>>    Dim Float UnReal
B>>   "i"
B>>  }0  ' 0-это подстрочное значение. Обозначающее, что находящееся в скобках может остутсвовать
B>> }
B>>

S>Непонятно. Что это будет означать? Как записываются комплексные числа в программе? Как обрабатываются конфликты разбора правил?
Записываются как принято обычно (i исправил). Отличие только в том, что определение типов не только служит для выделения памяти, но и является формулой для лексического разбора значений определяемых новым типом.
А возможные конфликты обнаруживаются анализом формул грамматики.

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

S>Это аналог спекулятивных оптимизаций, выполняемых, к примеру, для инлайнинга виртуальных вызовов. Вам знакома эта техника?
Понятно, так понятно. Это не сложный алгоритм. Пропустим.

S>При этом если бы мы не распараллеливали алгоритм, а тупо занимали бы один процессор, то обрабатывали бы 16 запросов в секунду. В самом-самом лучшем случае, если нам удалось построить идеально распараллеленный алгоритм без накладных расходов, то мы получили бы те же самые 16 картинок в секунду. Это математика — её не обманешь.
S>Именно так работают большинство современных веб-приложений. Потому что рулит throughput до тех пор, пока response time приемлемый. Если запрос обрабатывается один час, то пользователю малоинтересно, что одновременно с ним обрабатывается ещё 1000 запросов. Он предпочтёт чтобы его запрос обработался за 4 секунды, а остальные пусть потом обрабатываются.

S>Про переупорядочивание команд также поясню, что это не совсем распараллеливание. Это учёт архитектуры конкретной целевой машины. Алгоритм при этом по-прежнему остаётся последовательным — процессор следит за тем, чтобы переупорядочивание и переименование не нарушили семантику. От компилятора требуется эффективно загрузить конвеер — а для этого рулят классические оптимизации типа инлайнинга, устранения мёртвого кода, распространения константы, и прочего. Вы же читали Аппеля, не так ли?
Аппеля не читал. Дай ссылку. А с остальным согласен. Трудно не согласиться, когда оно так и есть

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

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

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

К>>[занудность on]
К>>Интересно, как может математик и не знать почему для комплексных чисел используется буква i?

К>>(hint: речь про UnReal, в котором к том уже используется довольно странное обхождение с регистром...)
К>>[занудность off]
B>Клянусь, переключал регистр

Заметил при редактировании, но не проверил как отредактировалось...

Для находящихся глубоко в бронетехнике: есть такое слово imaginary

Здравствуйте, batu, Вы писали:
B>Даже не обольщайтесь! Во первых вы редкий собеседник по уровню общения, во вторых вы из новосибирска. А там живет моя сестра. Так что как оппонент вы просто великолепный и незабываемый.
Какое совпадение! Моя сестра тоже живёт в Новосибирске. Есть у нас что-то общее.

B>Нет аргументов. Вообще-то я предполагал наличие отдельного "диспечтера событий", но это вполне можно реализовать и в библиотеке.
Именно это я и имел в виду. Возможно, встраивание событий прямо в язык может дать какие-нибудь преимущества, но надо сначала понять, какие недостатки есть в использовании библиотеки. Утрированный пример: если бы в языке C не было встроенной поддержки для ASCIIZ-строк, то описание строковых констант в программе было бы сущим мучением — несмотря на то, что всё остальное вроде бы представляется библиотекой. Никто не захочет описывать "Hello" как{'H', 'e', 'l', 'l', 'o', 0}.

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

S>>Это аналог спекулятивных оптимизаций, выполняемых, к примеру, для инлайнинга виртуальных вызовов. Вам знакома эта техника?
B>Понятно, так понятно. Это не сложный алгоритм. Пропустим.

B>Аппеля не читал. Дай ссылку. А с остальным согласен. Трудно не согласиться, когда оно так и есть

http://www.cs.princeton.edu/~appel/modern/
Особенно рекомендую вторую часть.

	От:	batu
	Дата:	22.09.10 11:57
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	22.09.10 12:15
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	22.09.10 12:34
Оценка:

	От:	batu
	Дата:	22.09.10 12:55
	Оценка:

	От:	vadimcher
	Дата:	22.09.10 16:27
	Оценка:	+1

От:	Курилка	http://kirya.narod.ru/
Дата:	23.09.10 09:35
Оценка: