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

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

B>Хотелось заменить все языки одним. Фактически получилось два. Один TLL его можно назвать теговым. Каждый тег-это объект. Второй язык высокого уровня LADA, однако существует взаимно-однозначное соответствие этих языков. Потому можно считать TLL ассемлером LADA. Понятно, что для работы этих языков необходима виртуальная машина, но об этом позже.
B>Общие слова обо всем этом в файле Введение. И два файла с описанием языков. Введение.rar TLL.rar Lada.rar
B>Ссылаться на авторитеты не буду. Скажу только что на лето планируется все это реализовать. Собирается команда. Хотелось бы конструктивной критики. С уважением ко всем, кто уделит время на чтение и выскажет свою точку зрения.

B>Тишина. Хоть кто-то скачал что б почитать?

Так спорили о перспективном языке.. Хоть бы обматюкали.. и то легче б стало..

* Вам не кажется, что не нужно заставлять людей скачивать архив (то есть потом его ещё надо распаковывать) с одним документом, чтобы просто узнать о чём вообще речь?

* Нет простого описания идеи. Какова идея? Сделать всё лучше? Лучше чем что? Нет фона для сравнения.

* Цитата из введения. "Освободить голову разработчика от неестественных «заморочек» и условностей, которыми буквально нашпиговано программирование и вообще работа с компьютером, это значит сконцентрировать усилия на решение поставленной задачи." Вы делаете наоборот. Вводите десятки своих, новых понятий, давая им имена, которые ежедневно используются людьми в совершенно другом смысле (это называется запутывание), я говорю о таких ваших "инновациях", как понятия, материализация, стили, роли, модели, сценарии, преценденты...
У вас там была цитата Эйнштейна, так вот, то что вы описали — выглядит очень сложно. Намного сложнее, чем нужно, не то что можно.

Краткий справочник. Слева ваше инновационное название, справа название из реального мира.

Понятие (determination) — парсер (parser).
Роль — интерфейс.
Элемент — final class [Java], sealed [C#].
Быстрое и/или/нет — и/или/нет.

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

* Очень ярко видно чем ваш язык лучше, чем Algol, FORTRAN, Ada. Но в 2010 году многие их никогда и не видели, а на фоне современных языков какие преимущества? С какими современными (то есть созданными после, хотя бы, 1980 года) языками вы работали больше 2х месяцев?

* Принудительный асинхронный ввод-вывод: отлично. Моё глубочайшее почтение.

В целом впечатление такое:
Вы хотели утереть нос языкам своей молодости. Вам это удалось, но прошло столько лет, что эта идея не стоит ни одного вечера. Люди придумали много новых, интересных идей. А вы изобретали свой велосипед.
Преподнесено в жутко переусложнённом (в частности, от переименования) виде.
Есть много попыток (сложно сказать об успешности, ведь примеров настоящего полезного кода нет) совместить некоторые идеи в целостную форму.
В одну кучу свалено описание языка, стандартной библиотеки и идей по поводу какого-то редактора, окружения, чуть ли не Своей Операционной Системы.

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

B>Тишина. Хоть кто-то скачал что б почитать?

... Хоть бы обматюкали.. и то легче б стало..

Скачал, постараюсь в ближайшее время почитать. Обматюкать не обещаю, ибо не уверен, что понимаю, в чем Ваши трудности. Вдруг чего...

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

Для начала было бы неплохо выкладывать Ваши опусы в более портабельных форматах, нежели DOC.

>Тишина. Хоть кто-то скачал что б почитать?

Так спорили о перспективном языке.. Хоть бы обматюкали.. и то легче б стало..

"Идея, в общем-то, простая. Описание класса и есть описание формата. Получившийся выигрыш это единый редактор и единая среда выполнения. Загрузкой данных теперь занимается система. Имея старое и новое описание класса (и правила) можно обеспечить наследственность версий. Понятие приложений отсутствует за ненадобностью. Так что этот редактор он же среда выполнения заменяет и браузеры, и трансляторы и редакторы и вообще все."

Дальше читать не стал.

Идея объединения данных и кода работает в ОО ЯП потому, что в экземпляре класса содержится лишь ссылка на код (указатель на vtable), таскать же код везде и всюду за данными нерационально. Вот представь, у меня за стенкой сидит моделер, у которого на машине более тысячи 3d моделек всякой всячины, т.е. это получается более тысячи копий 3dMax'а... Ещё более забавно, если при обновлении страницы я каждый раз буду выкачивать новый браузер.
В общем с первых строк — фу!

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

B>Хотелось заменить все языки одним. Фактически получилось два. Один TLL его можно назвать теговым. Каждый тег-это объект. Второй язык высокого уровня LADA, однако существует взаимно-однозначное соответствие этих языков. Потому можно считать TLL ассемлером LADA. Понятно, что для работы этих языков необходима виртуальная машина, но об этом позже.

Я категорически против второго языка LADA! Ничего хорошего с таким названием не получится.

Так спорили о перспективном языке.. Хоть бы обматюкали.. и то легче б стало..
Так получилось что под моим ником разместили материал без моего ведома. Хотя надо сказать спасибо этому челу за то, что я здесь появился. Тот материал устарел. Вот новые документы. Думаю тут будет понятней концепции нового языка. TLL без изменений, а Lada изменилась здесь

ну теперь я уже принципиально не буду скачивать архив

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

CU>ну теперь я уже принципиально не буду скачивать архив
Дело личное

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

CU>>ну теперь я уже принципиально не буду скачивать архив
B>Дело личное

Ага. Лично. И лично я тоже не буду. Если автор даже на такие мелочи не реагирует, то езяк его точно никому не нужен будет.

Начните с создания нормальной HTML-странички.

Здравствуйте, batu, Вы писали:
B>Вот новые документы.
Ни х не понятно. Правда. Было бы здорово увидеть краткое описание, прочитав которое, обитатели rsdn заинтересовались бы.

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

MC>Здравствуйте, batu, Вы писали:
B>>Вот новые документы.
MC>Ни х не понятно. Правда. Было бы здорово увидеть краткое описание, прочитав которое, обитатели rsdn заинтересовались бы.
Я понимаю что не просто. И необычно. Ну, хотя бы три раздела можно освоить.. Проще чем написал пока не могу. В общении проще будет освоить..

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

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

CU>>>ну теперь я уже принципиально не буду скачивать архив
B>>Дело личное

VD>Ага. Лично. И лично я тоже не буду. Если автор даже на такие мелочи не реагирует, то езяк его точно никому не нужен будет.

VD>Начните с создания нормальной HTML-странички.
Какие мелочи? Ну, как есть пока..

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

VD>>Начните с создания нормальной HTML-странички.
B>Какие мелочи? Ну, как есть пока..

Мелочи — это то, что людям не удобно читать ваши описания. На это указало много народа.

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

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

VD>>>Начните с создания нормальной HTML-странички.
B>>Какие мелочи? Ну, как есть пока..

VD>Мелочи — это то, что людям не удобно читать ваши описания. На это указало много народа.
А как сделать что б было удобно? В двух страницах никак не получится.

Здравствуйте, batu, Вы писали:
MC>>Ни х не понятно. Правда. Было бы здорово увидеть краткое описание, прочитав которое, обитатели rsdn заинтересовались бы.
B>Я понимаю что не просто. И необычно. Ну, хотя бы три раздела можно освоить.. Проще чем написал пока не могу. В общении проще будет освоить..
Введение недоступно. TTL описывает какую-то xml-подобную нотацию. Lada — какой-то бейсикоподобный язык. Это все, что я понял. Мне все это напомнило какие-нибудь труъ-промышленные стандарты от какой-нить OMG, где стараются не называть вещи своими именами — не дай бог читатель что-то поймет.

VD>>>>Начните с создания нормальной HTML-странички.
B>>>Какие мелочи? Ну, как есть пока..

VD>>Мелочи — это то, что людям не удобно читать ваши описания. На это указало много народа.
B>А как сделать что б было удобно? В двух страницах никак не получится.

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

Но, пожалуйста, сделайте так чтоб это можно было просто посмотреть, без скачиваний и архивов.

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

MC>Здравствуйте, batu, Вы писали:
MC>>>Ни х не понятно. Правда. Было бы здорово увидеть краткое описание, прочитав которое, обитатели rsdn заинтересовались бы.
B>>Я понимаю что не просто. И необычно. Ну, хотя бы три раздела можно освоить.. Проще чем написал пока не могу. В общении проще будет освоить..
MC>Введение недоступно. TTL описывает какую-то xml-подобную нотацию. Lada — какой-то бейсикоподобный язык. Это все, что я понял. Мне все это напомнило какие-нибудь труъ-промышленные стандарты от какой-нить OMG, где стараются не называть вещи своими именами — не дай бог читатель что-то поймет.
Ну, какой же к черту XML? Там теги, а у меня каждый тег-это объект. Это ж принципиальная разница. Объект с вложенными объектами. И причем тут Бейсик.. Ну, что выдумывать знаки лишь бы отличалось? Есть имена классов которые уже привычны. Вот их и оставил. Остальное все другое. Более того этот же язык не только для классов (то бишь программ), но и для формирования документов годится.. Почитайте хотя бы три раздела. В введении четко написаны три новые концепции. Щас я их здесь выложу

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

VD>>>>>Начните с создания нормальной HTML-странички.
B>>>>Какие мелочи? Ну, как есть пока..

VD>>>Мелочи — это то, что людям не удобно читать ваши описания. На это указало много народа.
B>>А как сделать что б было удобно? В двух страницах никак не получится.

T>Не надо в двух. Сделайте одну страницу с кратким описанием, расскажите об идее вашего языка, о сходствах и отличиях с другими современными (это очень важно). А дальше хоть на сто двух страницах — подробности.

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

Концепции.

Язык системы Lada является объектным, как и многие языки. Он является не столько языком, сколько системой правил создания, редактирования, хранения и протоколом обмена объектов, которые должны соблюдать языки, работающие в системе Lada. Эти правила общие и для создания текстовых документов (на других языках), и для создания, хранением и редактирования любых данных, а могут быть и языком программирования. Для программирования имеются средства императивного представления объекта (со свойствами, методами и событиями), элементы фунционального программирования, так и логическое представление объекта (представление в виде высказывания). Кроме того сделана попытка универсализации синтаксиса определения объектов. И дело не в желании автора сделать что-то оригинальное, а как раз наоборот привести к единому виду. Для этого проработаны три концепции. А именно:

1. Правила именования объектов.
2. Правила реализации объекта (Присвоение значений свойств, добавление новых свойств, методов и событий).
3. Правила группирования объектов. Объединение объектов.

Ниже обосновывается необходимость наличия этих трех правил в ООП, подробное описание которых в соответствующих разделах документа, а здесь хотелось бы отметить, что каждый объект в системе Lada имеет как императивное представление со свойствами, их значениями и методами, так и логическое представление объекта.
По поводу необходимости именования объектов вопросов быть не должно. С помощью имен мы имеем возможность идентифицировать объект. Так что правила именования объектов должно состоять из двух частей правила присвоения имени объекту и правила использование имени как инструментом доступа к объекту. Обычно имя объекта уникально в какой-то области. В системе Lada уникальность имени не обязательна для всех классов (Раздел 1).
Что бы не погрязнуть в деталях правил реализации и группирования отметим очевидное: При определении объекта необходимо иметь средства для присваивания значений свойств (те же операторы присваивания). Кроме того было бы весьма желательно иметь возможности для доопределения свойств, методов и событий для объекта. И совсем, очевидно, что операторы все это выполняющие должны быть как-то объединены (скобками, конечно) для восприятия их как единого целого. Стало быть, необходимо иметь правила применения скобок или как мы назвали правила группирования (Раздел 2).
Содержимое скобок доопределяющих объект и назовем реализацией. Реализация состоит из присваивания свойств и операторов. Для четкого понимания сути реализации необходимо отличать методы создания объектов и этапы трансляции и выполнения. Первый метод создания объекта, это создание букв (знаков), лексем и значений. Объекты-знаки обычно создаются набором на клавиатуре. Объекты лексемы и значения возникают из группы знаков в результате лексического анализа. Поясним это на примере. Так следующий текст
For I=30 To N {J +:= 1}
в результате лексического анализа разделяется на лексемы «For», «I», «=», «30», «To» и т.д. В этом смысле «For», «I» и«To» объекты-лексемы класса «Word». Итак, мы видим что объект «I» можно рассматривать как объект-букву и как лексему класса Word. Именно эти объекты (полученные в результате лексического анализа) будут поданы как входная цепочка в синтаксический анализатор (и далее в семантический). В результате работы синтаксического анализатора из последовательности лексем будет создан объект класса For с именем I, который в свою очередь может нуждаться в реализации. Отдельно остановимся на объектах-значениях. В нашем примере в результате лексического анализа из знаков «30» создастся объект класса Integer и значением 30. Это и есть объект-значение. Объектами-значениями мы назовем объекты, порождаемые классом Type и имеющие цифровое или текстовое представление. Например, «21», «100кг» или «1 октября 1995г». Эти же объекты можно получить из общего синтаксиса. Например, из такой синтаксической конструкции Integer I=30 в результате трансляции будет так же получен объект класса Iinteger со значением 30 и по имени I.
Итак, имеем иерархию объектов. Сначала объекты-знаки, затем объекты лексемы и следующий уровень это объекты, получаемые в результате трансляции при анализе синтаксиса. С помощью реализации можно изменить свойства и наполнить функциональным содержанием объект. По причине того, что изменение свойств и выполнение функционала необходимо выполнять на разных этапах и существует несколько видов реализации. Так реализация объектов-знаков, лексем и значений происходит на этапе лексического разбора и определяется скобками (лексические скобки) «‘» «’». Реализация объекта-знака следует непосредственно за этим знаком без пробела. Реализация лексем и значений осуществляется через пробел после реализуемого объекта. И выполняется во время лексического анализа. Реализация объектов создаваемых синтаксисом подчиняется правилам группирования, т.е. фигурными, круглыми или квадратными скобками и выполняется при запуске оттранслированной программы. Подробнее о применении скобок в правилах группирования см. раздел 2. Кроме этого каждый объект может содержать логическую реализацию, которая осуществляется скобками (логические скобки) «‹» и «›». И, наконец, реализация имен осуществляется скобками «“» и «”». Смысл реализации имен в том, что объект или группа объектов (например, функций или понятий) может быть вызвана по имени и выполнена (возможно, с параметрами), но после выполнения объекта, может быть необходимо выполнение каких-то еще действий. Вот такую реализацию и назовем реализацией имен или метареализация. Раздел 3.

Создание объектов.

Объекты могут порождать три класса Class, Type и Instruction. Все эти классы порождают объекты. Отличия в следующем:
Классы Class порождают объекты, эквивалентность которых определяется равенством ссылок. Операции сравнения объектов (и равенства в том числе) в языке Lada определяются отдельно.
Классы Type порождают объекты-значения. Операция эквивалентность для значений не определена. Здесь имеет смысл говорить о равенстве. Кроме того, объектам-значениям могут присваиваться значения, выраженные в числовом и/или текстовом виде. По этой причине определение типов оказывает влияние на лексически разбор, и, следовательно, документ (объекты класса Document являются загрузочной единицей) в котором определяются типы, должен быть, оттранслирован до трансляции документа использующего значения этого типа. Для этого используются библиотеки, пространства и механизм сценария, о котором расскажем позже.
Классы Instruction создают инструкции. Конструктор этого класса является содержанием инструкции. Примерами объектов-инструкций являются операторы языка, такие как For, If и прочие. И понятно, что можно создавать пользовательские инструкции.
Во время выполнения документа объекты можно создавать операторами New, Dim и Var. При создании объекта оператором New создается объект (и ссылка) в области, выделяемой динамически и этот объект доступен до тех пор, пока существует хоть одна ссылка не него (оператором присваивания) или на его свойства. Оператор New можно применять ко всем объектам, создаваемым классами Class, Type и Instruction.
Второй способ создания данных оператором Dim. В этом случае область данных так же выделяется динамически, однако данные доступны только в области определения этой переменной, что характерно для значений. Область данных освобождается сразу при выходе из области определения. Оператор Dim можно применять ко всем объектам, создаваемым классами Class, Type и Instruction.
Данные определенные оператором Var используются внутренним сценарием для выполнения в режиме интерпретатора. В этом же режиме выполняются все операторы с объектами-значениями, статическими данными, и данными внешними и внутренними сценариями. Так, например, будут выполнено в тексте сложение 2+7 и такая последовательность

Var Integer (I, J)
I:=2+7
J:=17*5
New Form FO {Size=: I; J}

И при запуске программы будет создана форма с размерами 9 на 85. Или, например, можно выполнить условный оператор.

Var Boolean F=True
Select
{ If F {Объекты для условия True}
Else {Объекты для условия False}
}

Здесь в качестве объектов фактически используется текст. Потому если редактируемый текст является программой, то в ее тексте будет в наличии только участок соответствующий условию True. Таким способом можно выполнять не только условные операторы, но и операторы цикла.

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

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

Здравствуйте, batu, Вы писали:
B>Ну, какой же к черту XML? Там теги, а у меня каждый тег-это объект. Это ж принципиальная разница. Объект с вложенными объектами.
А в xml что по-твоему? Объекты. Со вложенными объектами. И с атрибутами.

B>И причем тут Бейсик.. Ну, что выдумывать знаки лишь бы отличалось? Есть имена классов которые уже привычны. Вот их и оставил. Остальное все другое.
Не в именах дело. В парадигме. Я смотрел на примеры программ и увидел примитивы структурного программирования (то, что я назвал бесиком) и элементы логического программирования.

B>Более того этот же язык не только для классов (то бишь программ), но и для формирования документов годится..
Xml!

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

VD>>Мелочи — это то, что людям не удобно читать ваши описания. На это указало много народа.
B>А как сделать что б было удобно? В двух страницах никак не получится.

На то есть ссылки.

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

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

B>>Более того этот же язык не только для классов (то бишь программ), но и для формирования документов годится..
MC>Xml!
Мне кажется чуть лучше чем XML.
Синтаксис: "Имя класса" "Имя объекта" "Реализация"
Т.е.
Form Fo -это и есть объект форма. А в фигурных скобках (реализация) можно присвоить свойства.
For I=0 To 25 {...} тоже объект класса For с именем I и с реализацией. Но в реализации функциональное наполнение.
Dim Form Fo {Size=:20;120} — объект класса Dim создающий объект класса Form размерами 20 на 120.

От такой комбинации
Dim Form Fo
Fo.Size:=20;120 отличается тем, что в последнем случае значения свойства Size выполняется командами Move при выполнении, а в первом случае размеры формы создается при создании формы, так как значения храняться.
Если заметили и разные операции присваивания свойства "=:"и обычного присваивания":=".

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

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

D>Прочитал, в основном вода и никакой конкретики.
D>Предлагаю сыграть в игру: ты продавец, я покупатель. Продай мне свой язык.
D>У меня есть проблемы и потребности. Как он может их удовлетворить?
А чем занимаешься? Я найду аргументы для твоей работы

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

B>А чем занимаешься? Я найду аргументы для твоей работы

Разрабатываю компьютерные игры.

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

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

B>>А чем занимаешься? Я найду аргументы для твоей работы

D>Разрабатываю компьютерные игры.
Увы! Пока ничем не могу помочь. Я не уверен в том, что мои инструменты будут эффективнее ассемблеров C++ и прочих наработок создателей игр. Для систем реального времени тоже еще рано заикаться. Предусмотрен механизм событий, но эффектиность пока не проверена. Никаких рекомендаций пока дать не могу.

А назначение языка то какое?

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

B>Увы! Пока ничем не могу помочь. Я не уверен в том, что мои инструменты будут эффективнее ассемблеров C++ и прочих наработок создателей игр.

C++ используется менее чем в половине кода. Редактор написан на C# и С++/CLI.

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

Ясно.

Здравствуйте, batu, Вы писали:
B>Мне кажется чуть лучше чем XML.
А чем лучше?

B>Синтаксис: "Имя класса" "Имя объекта" "Реализация"
Ну и в xml получается <ИмяКласса name="ИмяОбъека">Реализация</ИмяКласса>.
Ессно, возможны варианты, но имя элемента проще использовать в качестве имени класса. Для имени объекта специального места нет — так что можно использовать какой-то определенный атрибут. Короче, один в один с тем, что у тебя.

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

M>А назначение языка то какое?
Это часть системы. Язык можно использовать, от создания документов, до написания программ. Причем можно создавать программу как интерпретатор, как текстовый редактор (а по большому счету как редактор объектов) или как три варианта сразу. На этом языке можно писать трансляторы для других языков (причем сразу получается и редактор и транслятор нового языка). Механизм событий позволяет реализовывать автоматы (устройства) и машину управляемую потоками данных (Посмотрите примеры в разделе события). Можно так же создавать программы основаные на парадигме функционального программирования и использовать элементы логического программированя. Вообщем достаточно большой спектр инструментов в одном флаконе.
О системе пока скажу что предусмотрен единый формат данных (в смысле объектов) основаный на описании класса, и он же является базой для универсального редактирования и протоколом обмена. Приложений нет. Только классы и библиотеки. Все работает в среде универсального редактора являющимся и редактором и браузером и Exel и UML а также конвертором в TLL, который выполняет роль ассемблера для языка высокого уровня.
Достаточно серьезная заявка. Но, демка работает

Разработка хорошо ложится на существующую архитектуру компьютера (Возможно хорошо пошла бы машина тьюринга с дополнительной адресной лентой, но это уже через чур хорошо что бы помечтать)потому есть надежды что будет работать эффективно. Но, это еще не факт. По большому счету желательно сделать аппаратную обработку запуска событий. Это позволит выполнять их параллельно. По этим причинам пока не могу рекомедовать для систем реального времени и разработки игр. Для остальных задач масса преимуществ. О которых буду рассказывать постепенно по мере поступления задач. Считаю что получится достойный конкурент JAWA.

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

MC>Здравствуйте, batu, Вы писали:
B>>Мне кажется чуть лучше чем XML.
MC>А чем лучше?

B>>Синтаксис: "Имя класса" "Имя объекта" "Реализация"
MC>Ну и в xml получается <ИмяКласса name="ИмяОбъека">Реализация</ИмяКласса>.
MC>Ессно, возможны варианты, но имя элемента проще использовать в качестве имени класса. Для имени объекта специального места нет — так что можно использовать какой-то определенный атрибут. Короче, один в один с тем, что у тебя.
Да похоже. Но в моей формулировке транслятор проще. А это принципиальнно потому как его можно прошить, и сразу загрузить мою виртуальную машину программу не только двоичную, но и в текстовом виде. Я не думаю что такие сложности в XML обоснованы. В том числе и скобки и слэш в закрывающей скобке. Да и семантический смысл. Заметь что скобка с именем (именованая скобка) это вроде как для каждого класса свой вид скобок. А содержимое-свойства объекта данного класса и объекты. И никаких больше правил. Если не считать комментирования

Здравствуйте, batu, Вы писали:
B>Да похоже. Но в моей формулировке транслятор проще. А это принципиальнно потому как его можно прошить, и сразу загрузить мою виртуальную машину программу не только двоичную, но и в текстовом виде.
B>Я не думаю что такие сложности в XML обоснованы. В том числе и скобки и слэш в закрывающей скобке.
Это все детали текстового представления. Оно далеко не первично. Первична объектная модель: документ-элемент-атрибут-и.т.д.
Внешнее представление для xml-документа можно использовать свое, не теряя большую часть инструментов (xsd/xstl/xpath/xquery) — надо только реализовать свой парсер.

B>Да и семантический смысл. Заметь что скобка с именем (именованая скобка) это вроде как для каждого класса свой вид скобок.
Ты переусложняешь.

B>А содержимое-свойства объекта данного класса и объекты. И никаких больше правил. Если не считать комментирования

Сорри, не уловил мысль.

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

MC>Здравствуйте, batu, Вы писали:
B>>Да похоже. Но в моей формулировке транслятор проще. А это принципиальнно потому как его можно прошить, и сразу загрузить мою виртуальную машину программу не только двоичную, но и в текстовом виде.
B>>Я не думаю что такие сложности в XML обоснованы. В том числе и скобки и слэш в закрывающей скобке.
MC>Это все детали текстового представления. Оно далеко не первично. Первична объектная модель: документ-элемент-атрибут-и.т.д.
MC>Внешнее представление для xml-документа можно использовать свое, не теряя большую часть инструментов (xsd/xstl/xpath/xquery) — надо только реализовать свой парсер.
Не совсем так. В xml первые теги идут с атрибутами (я это свойтсвами называю) документа, язык, пользователь и прочее идет отдельным тегом (или объектом). И возникает вопрос с областью определения этих атрибутов. Более логично что бы объекты на которые распостранется действие объекта (и его атрибутов) содержались в объекте. Иначе нет общности. Получается это не объект, а какой-то настройщик среды. И, следовательно эта среда где-то существует отдельно. А это накладывает ограничение. Так как функциональное наполнение объекта получается вне самого объекта.

B>>Да и семантический смысл. Заметь что скобка с именем (именованая скобка) это вроде как для каждого класса свой вид скобок.
MC>Ты переусложняешь.

B>>А содержимое-свойства объекта данного класса и объекты. И никаких больше правил. Если не считать комментирования

MC>Сорри, не уловил мысль.
Та я атрибуты свойствами назвал. Называют и полями. Это не принципиально. Принципиальна вложенность.

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

Согласись, более логично, что бы функциональное содержание объекта распостранялось на объекты содержащиеся в нем, а не на объекты вне его. Это позволяет изменять и совершенствовать конкретный объект, а не всю среду (фактически виртуальную машину) в которой он функционирует. Хотя предусмотрены и такие варианты, тогда объекты связываются событиями. Это отдельная тема и рассмотрена а языке Lada. Между Lada и TLL взаимно-однозначное соответствие.

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

B>[покоцано] Для остальных задач масса преимуществ. О которых буду рассказывать постепенно по мере поступления задач. Считаю что получится достойный конкурент JAWA.

Конкурент несуществующему языку — это, конечно, здорово.

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

поскипано

а где можно посмотреть сырцы, примеры, демки /etc?

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

B>Концепции.
...

С тоской (если не сказать — с зубной болью) вспомнил mkizub-а с его нетекстовым программированием...

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

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

RW>поскипано

RW>а где можно посмотреть сырцы, примеры, демки /etc?
Демка редактор и транслятор С TLL. Отрабатывал редактирование, кнопочки и прочую функциональную часть. Сделан года два назад. Поищу скину дня через два. Там схема работы такая, что встроены только системные теги (так называемая стартовая система)

System -определяет классы системы. (одновременно несколько систем могло работать)
Group- объединяет объекты
Class- создает класс
Dim-создает данные
Document-загрузочная единица.
Gate- этот тег добавляет в стартовую систему классы не определенные в стартовой системе для загрузки объектов классы которых не определены в системе.

Остальное все классы системы определяются при загрузке системы и, собственно, определяют и систему и грамматику которая превращается в транслятор.. Вообще задумано так что все грузится на основе этих 6 тегов. И их можно определять тоже. Для новой системы они можно переопределить. После загрузки стартовая система удаляется и работает та, что загружена. Можно загрузить несколько систем и языков и переключаться между ними. не знаю как для работы, а для отладки это здорово помогало.

Есть классы встроенной функциональности, но не определенные в стартовой системе. Такие как
Lexic-определяющий лексику языка
Syntax-синтаксис
Ну и можно другие определить заранее. Например, такие как операции сложения и т.п..

Язык lada пока только в текстовых документах. Вот выложил на обсуждение.
Так как все работало, я демку не трогал давно. Но, я думаю понятно как она работает. Нужно к ней загрузочный файл с системой.. Их у меня куча была.. Подберу и выложу кому интересно. Загрузка системы кажется была возможна в двоичном и текстовом виде.

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

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

B>>[покоцано] Для остальных задач масса преимуществ. О которых буду рассказывать постепенно по мере поступления задач. Считаю что получится достойный конкурент JAWA.

К>Конкурент несуществующему языку — это, конечно, здорово.

Пока не существующему. Внеси свою лепту. Я не обижусь

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

надо будет поглядеть, потому что почитав драфт хочется увидеть "мясо", Вы же как автор сиго языка(языков) могли бы продемоснтрировать общественности как, например, решить задачку Поиск повторяющегося числа в массиве с помощью языка. Была бы демонстрация в стиле "Hello, World", но уже с практическим смыслом. Да и мне интересно

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

B>>>[покоцано] Для остальных задач масса преимуществ. О которых буду рассказывать постепенно по мере поступления задач. Считаю что получится достойный конкурент JAWA.

К>>Конкурент несуществующему языку — это, конечно, здорово.

B>Пока не существующему. Внеси свою лепту. Я не обижусь

наверное, имелось ввиду, что нет такого языка как JAWA, если Java

ну опечатка, бывает

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

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

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

B>>>[покоцано] Для остальных задач масса преимуществ. О которых буду рассказывать постепенно по мере поступления задач. Считаю что получится достойный конкурент JAWA.

К>>Конкурент несуществующему языку — это, конечно, здорово.

B>Пока не существующему. Внеси свою лепту. Я не обижусь

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

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

B>Пока не существующему. Внеси свою лепту. Я не обижусь

А про лепту — почему не видно ссылки на розиторий на github/Google Code/etc.?

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

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

B>>>>[покоцано] Для остальных задач масса преимуществ. О которых буду рассказывать постепенно по мере поступления задач. Считаю что получится достойный конкурент JAWA.

К>>>Конкурент несуществующему языку — это, конечно, здорово.

B>>Пока не существующему. Внеси свою лепту. Я не обижусь

RW>наверное, имелось ввиду, что нет такого языка как JAWA, если Java

ну опечатка, бывает
Конечно.. И запятые не всегда на местах.. И буквы путаю..Сори за все.. Особенно за терминологию. Так для того и здесь что бы выслушать замечания, критику, а может и что-то конструктивное подскажете. На настоящий момент тональностью и обсуждением доволен. Всем заранее спасибо за все замечания.

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

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

RW>надо будет поглядеть, потому что почитав драфт хочется увидеть "мясо", Вы же как автор сиго языка(языков) могли бы продемоснтрировать общественности как, например, решить задачку Поиск повторяющегося числа в массиве с помощью языка. Была бы демонстрация в стиле "Hello, World", но уже с практическим смыслом. Да и мне интересно

Размер массива N. Максимальное значение M. Надстрочное значение определяю знаком ^. Подстрочное восклицательным знаком.
Как класс.

Function Integer Repeat (Ref Integer A[], Integer M)
{ Dim Integer AA[] {Value=:0}^M Инициализация группой. Выполняется M раз, по правилам группирования.
ForEach J In A
{ If AA!J<>0 Then { Repeat:= j Exit Function}
AA!J:=1
}
}

Как интерпретатор. Данные для анализа в группе A.

Group A (1, 2, 15, 5, 13, 3, 6, 2, 16) Данные
Integer AA[] {Value=:0}^M Это в классической формулировке статический массив. Никакими классами и динамическим созданием не пахнет.
ForEach J In A
{ If AA!J<>0 Then {Output (Screen, J)Exit ForEach}
AA!J:=1
}
Есть варианты решить методами функциональной или логической парадигмы, но для этой задачи это будет явно не эффективно.

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

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

B>>Пока не существующему. Внеси свою лепту. Я не обижусь

К>А про лепту — почему не видно ссылки на розиторий на github/Google Code/etc.?
Не задрачивай.. Если хочешь сам делай.. Кстати, и на этот сайт я попал не по собственному желанию.. Кто-то разместил здесь мои материалы, причем без моего согласия и под моим ником. Но, потом дал ссылку и пароль..Так я здесь появился..

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

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

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

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

B>>>>[покоцано] Для остальных задач масса преимуществ. О которых буду рассказывать постепенно по мере поступления задач. Считаю что получится достойный конкурент JAWA.

К>>>Конкурент несуществующему языку — это, конечно, здорово.

B>>Пока не существующему. Внеси свою лепту. Я не обижусь

К>Т.е. ты понял о чём я? Специально сейчас болдом выделил выше.
К>Скаладывается впечатление, что других участников ты также не очень понимаешь (которые говорят о более доступных и понятных материалах по твоему "вазу")
Давно проехали..

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

B>Здравствуйте, Курилка, Вы писали:
К>>А про лепту — почему не видно ссылки на розиторий на github/Google Code/etc.?
B>Не задрачивай.. Если хочешь сам делай.. Кстати, и на этот сайт я попал не по собственному желанию.. Кто-то разместил здесь мои материалы, причем без моего согласия и под моим ником. Но, потом дал ссылку и пароль..Так я здесь появился..

Теперь предельно понятен уровень желаемого общения, спасибо

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

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

B>>Здравствуйте, Курилка, Вы писали:
К>>>А про лепту — почему не видно ссылки на розиторий на github/Google Code/etc.?
B>>Не задрачивай.. Если хочешь сам делай.. Кстати, и на этот сайт я попал не по собственному желанию.. Кто-то разместил здесь мои материалы, причем без моего согласия и под моим ником. Но, потом дал ссылку и пароль..Так я здесь появился..

К>Теперь предельно понятен уровень желаемого общения, спасибо

Как есть..

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

CU>ну теперь я уже принципиально не буду скачивать архив

Я даже скачал. Но прочесть так и не смог — у меня файл растаращило до совершенно нечитабельного вида.

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

B>Хотелось заменить все языки одним. Фактически получилось два. Один TLL его можно назвать теговым. Каждый тег-это объект. Второй язык высокого уровня LADA, ...

Хочу рассказать одну историю. В 1999 году нас пригласили на одну презентацию. С презентации я вышел, можно сказать, одухотворенным, так как на ней было говорилось о новом Российском процессор Эльбрус 2000 "Модельные испытания (которого) показали, что он бьет по всем параметрам все ныне работающие и еще только проектируемые процессоры крупнейших электронных компаний мира." На презентации, вокруг сидело много скептиков смотревших на Бабаян (нового автора российского чуда) с подозрением и тих цикающих губами когда тот говорил о планах.

Вот что мы написали по этому поводу:
http://www.k-press.ru/cs/1999/1/e2k/e2k.asp

Почему я рассказал это? Да потому что у ЛАДЫ и этого процессора есть много общего — они оба существуют только на бумаге.

Попробуй реализовать все это дело и ты сразу поймешь почему это дело не может быть реализовано.

ЗЫ

Да, за прошедшие 10 лет и из лирика я потихонечку начал превращаться в циника.

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

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

B>>Хотелось заменить все языки одним. Фактически получилось два. Один TLL его можно назвать теговым. Каждый тег-это объект. Второй язык высокого уровня LADA, ...

VD>Хочу рассказать одну историю. В 1999 году нас пригласили на одну презентацию. С презентации я вышел, можно сказать, одухотворенным, так как на ней было говорилось о новом Российском процессор Эльбрус 2000 "Модельные испытания (которого) показали, что он бьет по всем параметрам все ныне работающие и еще только проектируемые процессоры крупнейших электронных компаний мира." На презентации, вокруг сидело много скептиков смотревших на Бабаян (нового автора российского чуда) с подозрением и тих цикающих губами когда тот говорил о планах.

VD>Вот что мы написали по этому поводу:
VD>http://www.k-press.ru/cs/1999/1/e2k/e2k.asp

VD>Почему я рассказал это? Да потому что у ЛАДЫ и этого процессора есть много общего — они оба существуют только на бумаге.

VD>Попробуй реализовать все это дело и ты сразу поймешь почему это дело не может быть реализовано.

VD>ЗЫ

VD>Да, за прошедшие 10 лет и из лирика я потихонечку начал превращаться в циника.

Я был в курсе этих работ. Авантюра то была. Потому и денег никто не дал. Новое,конечно, было. Но его было явно не достаточно что бы получить принципиальные преимущества. И, то, что этот проект не было смысла реализовывать я видел с самого начала. Когда научный сотрудник говорит про тайны и секреты значит ему нечего сказать. Идеи вещь хорошая, но сильную идею украсть не просто. Придумщик все равно знает больше. Вот прошло 10 лет и до сих пор ему нечего сказать про свои идеи. А мне есть. И я не спешу. Есть над чем работать. Единственно, что не нравится, никто так и не понял сути предлагаемого. Сам виноват. Потому сейчас пишу примеры. Так наглядней будет.
С уважением!

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

VD>>Да, за прошедшие 10 лет и из лирика я потихонечку начал превращаться в циника.

B>Я был в курсе этих работ. Авантюра то была. Потому и денег никто не дал. Новое,конечно, было. Но его было явно не достаточно что бы получить принципиальные преимущества. И, то, что этот проект не было смысла реализовывать я видел с самого начала. Когда научный сотрудник говорит про тайны и секреты значит ему нечего сказать. Идеи вещь хорошая, но сильную идею украсть не просто. Придумщик все равно знает больше. Вот прошло 10 лет и до сих пор ему нечего сказать про свои идеи. А мне есть. И я не спешу. Есть над чем работать. Единственно, что не нравится, никто так и не понял сути предлагаемого. Сам виноват. Потому сейчас пишу примеры. Так наглядней будет.

С виду идеи очень похожие — много слов, мал конкретики.

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

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

VD>>>Да, за прошедшие 10 лет и из лирика я потихонечку начал превращаться в циника.

B>>Я был в курсе этих работ. Авантюра то была. Потому и денег никто не дал. Новое,конечно, было. Но его было явно не достаточно что бы получить принципиальные преимущества. И, то, что этот проект не было смысла реализовывать я видел с самого начала. Когда научный сотрудник говорит про тайны и секреты значит ему нечего сказать. Идеи вещь хорошая, но сильную идею украсть не просто. Придумщик все равно знает больше. Вот прошло 10 лет и до сих пор ему нечего сказать про свои идеи. А мне есть. И я не спешу. Есть над чем работать. Единственно, что не нравится, никто так и не понял сути предлагаемого. Сам виноват. Потому сейчас пишу примеры. Так наглядней будет.

VD>С виду идеи очень похожие — много слов, мал конкретики.
Что именно интересует?

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

VD>>С виду идеи очень похожие — много слов, мал конкретики.
B>Что именно интересует?

Результат.

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

B>Хотелось заменить все языки одним. Фактически получилось два.

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

Чтобы "заменить все языки одним", нужно сначала заменить все модели вычислений одной. Если Вы именно это имеете ввиду, то Вам памятник можно будет поставить. Надо только так и сказать — вот я ввожу универсальную модель вычислений, которая лучше всех до сих пор существовавших, и продемонстрировать
сравнением новой модели с каждой из известных. Увы, сравнений моделей не увидел.

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

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

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

B>>Хотелось заменить все языки одним. Фактически получилось два.

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

rfq>Чтобы "заменить все языки одним", нужно сначала заменить все модели вычислений одной. Если Вы именно это имеете ввиду, то Вам памятник можно будет поставить. Надо только так и сказать — вот я ввожу универсальную модель вычислений, которая лучше всех до сих пор существовавших, и продемонстрировать
rfq>сравнением новой модели с каждой из известных. Увы, сравнений моделей не увидел.

rfq>Если же имелось ввиду заменить все языки одним в рамках какой-то одной модели, то это означает лишь, что Вы считаете свой язык удобнее и красивее всех других. Не Вы первый, не Вы последний. Опять же хотелось бы примеров-демонстраций, а не описаний синтаксиса.
Ты прав. Я об этом не рассказал. И прежде всего потому, что это не для всех. Имею я право на маленькую тайну? Совершенно верно, сначала была модель, а язык только реализовывал ее возможности.
К этому могу добавить что слова "Модель вычислений" касаются не только вычислений, а имеют общий смысл представления и обработки объектов. Операции и операторы у меня тоже объекты соответсвующих классов (класса If например). И "вычисление" этих и обычных объектов имеют общую модель. Я имел надежду, что изучающий язык потихоньку поймет суть. Здесь же много толковых ребят. А я не спешу. Работы еще много. Следи. Скоро повится описание еще одного маленького языка (всего 5 операторов и никаких типов кроме десятичных и логических). Он простенький, но там есть элементы из большого проекта. Должно быть любопытно.

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

B>Тишина. Хоть кто-то скачал что б почитать?

Так спорили о перспективном языке.. Хоть бы обматюкали.. и то легче б стало..

Странно, ничего не понял

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

Когда у меня только появился такой интерес, я просто брал существующие языки и задумывался — чего мне в них нехватает? Вот, вспоминаю простой пример: первый курс универа, изучение языка Си. Почему можно написать

func1("Hello world"); // void func1(char *s);

но нельзя

func2({100,200,300}); // void func2(int *a);

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

А в данном случае я честно ничего не понял.
1. Как вы пришли к идее нового языка? Чего вам нехватает в существующих? Каков вообще был ход Вашего мышления, когда вы проектировали этот язык?
2. На основе каких языков он основан? Я смотрю — не то паскаль не то бейсик...
3. Почему не Си-подобный (не тема для холивара, но если более 90% всех программ пишутся на си-подобных языках C/C++/C#/Java/ObjC/JavaScript/PHP/Perl/..., то зачем городить огород и разрывать программистам шаблоны?)
4. Самое главное — в чем фишка-то?

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

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

B>>Тишина. Хоть кто-то скачал что б почитать?

Так спорили о перспективном языке.. Хоть бы обматюкали.. и то легче б стало..

XC>Странно, ничего не понял

XC>Когда у меня только появился такой интерес, я просто брал существующие языки и задумывался — чего мне в них нехватает? Вот, вспоминаю простой пример: первый курс универа, изучение языка Си. Почему можно написать
XC>

XC>func1("Hello world"); // void func1(char *s);
XC>

XC>но нельзя
XC>

XC>func2({100,200,300}); // void func2(int *a);
XC>

XC>ну и так далее, в таком же духе. Т.е. брал язык и пытатся "дополнить" его до некой "целостности". Начинается, естественно, с мелочей, с "синтаксического сахара", но дальше нередко приходят интересные идеи.
Дополнять к языку это как учить папу трахаться. Язык не возникает откуда-то сверху по наитию. Язык это отражение некой модели. Ее можно назвать "вычислительной" дело не в названии. Но все языки (я имею в виду достойные начиная с фортрана, алгола, ады, с, джавы) являются результатом глубокой проработки и как оно будет "ложится" на архитектуру компьютера с одной стороны, и с другой стороны насколько близко семантически будет отражать природу вещей и "легкость" реализации этой природы. Сбалансировать эти три части и есть задача хорошего языка. Первые языки (ассемблер, фортран, алгол) хорошо "ложились" на компьютер, но вряд ли были семантически близки привычному миру. Но рванули вперед, хотя Lisp и пролог и на комп ложились достаточно хорошо (во всяком случае Lisp, с прологом проблемы эффективности не решены и по сей час.), но реализовывать программы был очень не просто. Еще хуже было с машинами управляемыми потоками данных. Они наиболее близко отражают природу вещей (не команды выполняются последовательно, а приходят данные и инициируют действия) Но там с написанием программ и изобретением языка возникла большая проблема. Потому и не пошли такие системы. Сейчас появилось много новых языков. ООП, прототипные языки. Основные парадигмы остались Императивная, функциональная, логическая и автоматная. Я считаю что современная тенденция идет к слиянию этих парадигм, построение общего синтаксиса, объектного подхода с гибкостью прототипных языков. Кроме того общего синтаксиса требует другая, не вычислительная часть применения компьютеров. Это и документирование, проектирование, базы данных, браузеры они тоже требуют своих языковых средств. Общего синтаксиса требует и нарастающий разрыв в синтаксисе и семантике языков, что порождает конфликты и непонимание между приверженцами какого-то (пусть и замечательного) языка.
Хорошо прошелся!

Про парсеры упустил..

XC>А в данном случае я честно ничего не понял.
XC>1. Как вы пришли к идее нового языка? Чего вам нехватает в существующих? Каков вообще был ход Вашего мышления, когда вы проектировали этот язык?
Начал с типов и классов. Но это было давно. Net еще не было. Кстати, посмотри. У меня это разные вещи. Класс порождает объекты, а тип-значения.
XC>2. На основе каких языков он основан? Я смотрю — не то паскаль не то бейсик...
И Си добавь. Фигурные скобки откуда?

XC>3. Почему не Си-подобный (не тема для холивара, но если более 90% всех программ пишутся на си-подобных языках C/C++/C#/Java/ObjC/JavaScript/PHP/Perl/..., то зачем городить огород и разрывать программистам шаблоны?)
Cи нравится. Удобный. Для тех кто привык. Там слишком много не естественных, но оправданых с точки зрения короткой формы обозначений. В принципе это хорошо. В дурака то играешь? И вот представь к правилам игры в дурака добавить правила типа четная карта числовая бъет картинку с таким же номером если считать снизу. А не четная... ну сам придумаешь.. Вот смысл и цель игры при этих новых правилах нисколько не изменится. Появится только дополнительная сушка мозгов. И вместо того что бы думать про саму игру будешь вспоминать все эти искусственные задрочки. А теперь вернемся к Си. Ну, и каким боком там восклицательный знак? Понял куда я клоню?
XC>4. Самое главное — в чем фишка-то?
Если б фишка была она я бы не вылезал с новым языком. Фишек там много. Основные, я вынес в первые три раздела. Это правила именования и формирования текста. Правило объединения объектов в группы и реализация объектов. Т.е. правила создания объектов. Это основное. Есть еще сильная вещь (обрати внимание) события. Это здорово облегчает программирование и стандартизирует взаимодействие между объектами. Кстати, позволяет создавать автоматы. Тоже интересная фича. Ну, оператор, например, новый есть Swith. Операция обмена тоже новая фишка. Распараллеливание с помощью групп.. А выполнение групп с надстрочным значением?

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

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

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

Про парсеры упустил..

XC>>А в данном случае я честно ничего не понял.
XC>>1. Как вы пришли к идее нового языка? Чего вам нехватает в существующих? Каков вообще был ход Вашего мышления, когда вы проектировали этот язык?
B>Начал с типов и классов. Но это было давно. Net еще не было. Кстати, посмотри. У меня это разные вещи. Класс порождает объекты, а тип-значения.
Вот уже конкретика, поясни НА ПРИМЕРЕ, что да как. В чем разница, что дает разделение понятий и т.д.

B>Cи нравится. Удобный. Для тех кто привык. Там слишком много не естественных, но оправданых с точки зрения короткой формы обозначений. В принципе это хорошо. В дурака то играешь? И вот представь к правилам игры в дурака добавить правила типа четная карта числовая бъет картинку с таким же номером если считать снизу. А не четная... ну сам придумаешь.. Вот смысл и цель игры при этих новых правилах нисколько не изменится. Появится только дополнительная сушка мозгов. И вместо того что бы думать про саму игру будешь вспоминать все эти искусственные задрочки. А теперь вернемся к Си. Ну, и каким боком там восклицательный знак? Понял куда я клоню?

Нет. Чем тебе не угодил восклицательный знак?
Если говорить чисто о синтаксисе Си, то он безупречен. В С++ есть проблема с конфликтом знаков '>' '<' и шаблонными скобками, но ты явно не об этом

XC>>4. Самое главное — в чем фишка-то?
B>Если б фишка была она я бы не вылезал с новым языком. Фишек там много. Основные, я вынес в первые три раздела.

Может, и вынес, но это понятно лишь тебе

У тебя в голове есть какая-то сложная философская модель языка, ты ее пытаешься выразить в тексте, всем кто пытаетя прочитать — ничего не понятно. Все познается в сравнении. Если хочешь донести до людей свои мысли, попытайся КАЖДУЮ фичу, каждое правило, каждую возможность языка продемонстрировать НА ПРИМЕРЕ. И сказать: вот в моем языке это делается так-то, а на C++/C#/Java это было вообще невозможно или требовало 5 экранов кода

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

Та много.. Вот хотя бы первые три концепции кто б осилил..
B>Надеюсь я подробно ответил? Если будут вопросы пиши. Всегда рад.

Было бы здорово, опять-таки, ПРИМЕРЫ по КАЖДОМУ пункту этого списка. Вот так — на твоем языке, а вот так — на C++/C#/Java. Сравнение реализаций, преимущества твоей реализации, недостатки существующей.

Только так и никак иначе

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

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

M>>А назначение языка то какое?
B>Это часть системы. Язык можно использовать, от создания документов, до написания программ.

По аналогии звучит как "инструмент для счастья во всем мире и ремонта холодильников"

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

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

XC>>>1. Как вы пришли к идее нового языка? Чего вам нехватает в существующих? Каков вообще был ход Вашего мышления, когда вы проектировали этот язык?
B>>Начал с типов и классов. Но это было давно. Net еще не было. Кстати, посмотри. У меня это разные вещи. Класс порождает объекты, а тип-значения.
XC>Вот уже конкретика, поясни НА ПРИМЕРЕ, что да как. В чем разница, что дает разделение понятий и т.д.
Разница между объектами и значениями (все они объекты мы здесь имеем ввиду объекты-объекты и объекты-значения) принципиальна. Объект может быть только один и равенство объектов означает что это один и тот же объект. Значений может быть сколько угодно и равенство значений это равенство всех свойств разных объектов значений. Отсюда и операция присвоения у объектов это копирование ссылки, а у значения копирование полностью объекта. Есть еще разница в том, что значение выражается текстом или цифрами. Например, Date=1 сентября 1995, Тор=65. Потому определение типов (они создают объекты-значения) оказывают влияние на лексический разбор. И т.д..Вообщем, есть разница, и тебе судить насколько она принципиальна.

B>>Cи нравится. Удобный. Для тех кто привык. Там слишком много не естественных, но оправданых с точки зрения короткой формы обозначений. В принципе это хорошо. В дурака то играешь? И вот представь к правилам игры в дурака добавить правила типа четная карта числовая бъет картинку с таким же номером если считать снизу. А не четная... ну сам придумаешь.. Вот смысл и цель игры при этих новых правилах нисколько не изменится. Появится только дополнительная сушка мозгов. И вместо того что бы думать про саму игру будешь вспоминать все эти искусственные задрочки. А теперь вернемся к Си. Ну, и каким боком там восклицательный знак? Понял куда я клоню?

XC>Нет. Чем тебе не угодил восклицательный знак?
XC>Если говорить чисто о синтаксисе Си, то он безупречен. В С++ есть проблема с конфликтом знаков '>' '<' и шаблонными скобками, но ты явно не об этом

И об этом тоже. Восклицательный знак просто как пример, а так очень его уважаю

XC>>>4. Самое главное — в чем фишка-то?
B>>Если б фишка была одна я бы не вылезал с новым языком. Фишек там много. Основные, я вынес в первые три раздела.

XC>Может, и вынес, но это понятно лишь тебе

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

Та много.. Вот хотя бы первые три концепции кто б осилил..
B>>Надеюсь я подробно ответил? Если будут вопросы пиши. Всегда рад.

XC>Было бы здорово, опять-таки, ПРИМЕРЫ по КАЖДОМУ пункту этого списка. Вот так — на твоем языке, а вот так — на C++/C#/Java. Сравнение реализаций, преимущества твоей реализации, недостатки существующей.

XC>Только так и никак иначе

Так там есть примеры.
Могу здесь по быстрому. Но, все нюансы (а они не нюансы) будет сложно. Вау.. Здесь не возможно. Скобки и надстрочные значения я здесь не смогу привести. Ну, почему бы не посмотреть примеры в документе? Там все есть... Хотя бы начнем с именования объектов и правил написания текста.. Можно даже пропустить правила описания грамматик. Они в самом начале документа. А потом по порядочку осваивать другие разделы. Я буду отвечать на вопросы.

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

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

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

M>>>А назначение языка то какое?
B>>Это часть системы. Язык можно использовать, от создания документов, до написания программ.

M>По аналогии звучит как "инструмент для счастья во всем мире и ремонта холодильников"
С холодильниками будут проблемы. А указаными задачами очень даже справляется. И удобнее чем в частности XML справляестся с единственной задачей. Если интересно, то укажу на принципиальные недостатки XML

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

Не знаю где ты смотришь, но здесь http://files.rsdn.ru/91645/LadaNew.rar сравнительно свежая версия

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

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

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

XC>>>>1. Как вы пришли к идее нового языка? Чего вам нехватает в существующих? Каков вообще был ход Вашего мышления, когда вы проектировали этот язык?
B>>>Начал с типов и классов. Но это было давно. Net еще не было. Кстати, посмотри. У меня это разные вещи. Класс порождает объекты, а тип-значения.
XC>>Вот уже конкретика, поясни НА ПРИМЕРЕ, что да как. В чем разница, что дает разделение понятий и т.д.
B>Разница между объектами и значениями (все они объекты мы здесь имеем ввиду объекты-объекты и объекты-значения) принципиальна. Объект может быть только один и равенство объектов означает что это один и тот же объект. Значений может быть сколько угодно и равенство значений это равенство всех свойств разных объектов значений. Отсюда и операция присвоения у объектов это копирование ссылки, а у значения копирование полностью объекта. Есть еще разница в том, что значение выражается текстом или цифрами. Например, Date=1 сентября 1995, Тор=65. Потому определение типов (они создают объекты-значения) оказывают влияние на лексический разбор. И т.д..Вообщем, есть разница, и тебе судить насколько она принципиальна.

Что-то понял, но какой-то неуловимый смысл... Для чего так? Есть константы и переменные. Есть передача по ссылке и передача по значению. Эти понятия можно комбинировать как угодно. Я могу захотеть передать "объект" как по ссылке, так и по значению. Точно так же имею право передать константу по значению, в твоей терминологии это будет уже объект, хранящий значение? В чем здесь новизна?

B>И об этом тоже. Восклицательный знак просто как пример, а так очень его уважаю

И все же, что с восклицательным знаком-то не так?

B>Так там есть примеры.
B>Могу здесь по быстрому. Но, все нюансы (а они не нюансы) будет сложно. Вау.. Здесь не возможно. Скобки и надстрочные значения я здесь не смогу привести. Ну, почему бы не посмотреть примеры в документе?

Еще раз: в документе непонятно. Напиши hello world на Lada, и еще пару примеров: реализацию двусвязного списка или очереди, сортировку какую-нибудь... С комментариями, и — повторюсь — со СРАВНЕНИЕМ твоей реализации и существующих.

Я вот дошел до первого примера и уже в ступоре

For I=30 To N {J +:= 1}

им дальше по тексту

В результате работы синтаксического анализатора из последовательности лексем будет создан объект класса For с именем I, который в свою очередь может нуждаться в реализации

а я то думал это обычный цикл с параметром...

Это какая-то попытка запихать инструкции (операторы языка) в парадигму ООП?

B>>И об этом тоже. Восклицательный знак просто как пример, а так очень его уважаю

XC>И все же, что с восклицательным знаком-то не так?

Извините, что вмешиваюсь, но недостаток восклицательного знака в Си очевиден: неинтуитивная семантика.
Вот сравните:

Ruby:

if messages.empty?  # true - да, список пустой
  user.logout!      # "опасный" метод, модифицирует состояние объекта. Немного истерично, но в этом хотя бы есть смысл.

if (!messages) {    // !messages что-это-за-хрень?
  user.logout();
}

Идея такова: чтобы читать код на C/Perl нужно знать эти языки; для Python/Ruby часто достаточно знать английский.

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

B>>Разница между объектами и значениями (все они объекты мы здесь имеем ввиду объекты-объекты и объекты-значения) принципиальна. Объект может быть только один и равенство объектов означает что это один и тот же объект. Значений может быть сколько угодно и равенство значений это равенство всех свойств разных объектов значений. Отсюда и операция присвоения у объектов это копирование ссылки, а у значения копирование полностью объекта. Есть еще разница в том, что значение выражается текстом или цифрами. Например, Date=1 сентября 1995, Тор=65. Потому определение типов (они создают объекты-значения) оказывают влияние на лексический разбор. И т.д..Вообщем, есть разница, и тебе судить насколько она принципиальна.

XC>Что-то понял, но какой-то неуловимый смысл... Для чего так? Есть константы и переменные. Есть передача по ссылке и передача по значению. Эти понятия можно комбинировать как угодно. Я могу захотеть передать "объект" как по ссылке, так и по значению. Точно так же имею право передать константу по значению, в твоей терминологии это будет уже объект, хранящий значение? В чем здесь новизна?
Не причем здесь новизна. Это классические вещи. Только я четко разделил. Когда есть разные сущности то они и должны быть разными. Присвоение и передачу параметров, это понятно что можно сделать и так и так.Только это чревато. Но вот как с присваиванием быть? Разные знаки делать? Ведь очевидно что суть этих операций разная для класов и типов. А операцию равенства? Для объектов эта операция заключается в равенстве ссылок, а для значений в проверке значения. Вот ты изменил свойство в объекте, например, зарплату или должность.. Объект должен гарантировано остаться тем же самым. И совсем другое дело если ты в объекте-дате изменил месяц! Получился ДРУГОЙ ОБЪЕКТ! Одинаковых объектов-значений могут существовать тысячи одновременно, а объект один и навсегда.

B>>И об этом тоже. Восклицательный знак просто как пример, а так очень его уважаю

XC>И все же, что с восклицательным знаком-то не так?
Да не задрачивай..

B>>Так там есть примеры.
B>>Могу здесь по быстрому. Но, все нюансы (а они не нюансы) будет сложно. Вау.. Здесь не возможно. Скобки и надстрочные значения я здесь не смогу привести. Ну, почему бы не посмотреть примеры в документе?

XC>Еще раз: в документе непонятно. Напиши hello world на Lada, и еще пару примеров: реализацию двусвязного списка или очереди, сортировку какую-нибудь... С комментариями, и — повторюсь — со СРАВНЕНИЕМ твоей реализации и существующих.

XC>Я вот дошел до первого примера и уже в ступоре

XC>

XC>For I=30 To N {J +:= 1}
XC>

XC>им дальше по тексту
XC>

В результате работы синтаксического анализатора из последовательности лексем будет создан объект класса For с именем I, который в свою очередь может нуждаться в реализации

XC>а я то думал это обычный цикл с параметром...

XC>Это какая-то попытка запихать инструкции (операторы языка) в парадигму ООП?
Рассказываю. Когда ты пишешь буквы они тоже объекты. Потом из букв сконструировал слово (в нашем примере For) так вот как слово это самостоятельный объект и другого класса чем буквы, т.е. со своими собственными свойствами. Если у букв есть шрифты, размер и прочее (кстати, я категорически против что б буквы имели свойство язык), а у слова свои свойства как у самостоятельного объекта воспринимаемого как единое целое а не то из чего оно состоит. Класс и свойства этого объекта (создание объекта For класса "Lexem" ) определяется при лексическом анализе. Как и все остальные лексемы. А уже при трансляции в синтаксическом анализаторе из последовательности лексем и знаков согласно синтаксису создается объект класса For. Да, это такой же объект. Вот и если речь идет о программе то создается объекты-инструкции. Это еще один тип объектов плюс к объектам-значениям.
Дальше совсем просто. Если мы хотим создать форму BB то так и пишем Form BB. Так в результате трансляции создастся объект этого класса.
А теперь проблема!
Int I=10 что создаст при трансляции? Обычно в языках в такой форме синтаксиса создается (скрытая от глаз) инструкция срабатывающая во время выполения (а не трансляции), и создающая динамически целую переменную где-то в выделеной области памяти.
У меня создается именно целое значение =10 в этом месте. Для того, что бы во время выполнения создать такое значение (или такие значения если это в классе и есть вариант одновременного вызова) необходимо иметь еще одну инструкцию которую необходимо применить к этому объекту для динамического создания. И эта инструкция есть. Даже три! New, Dim и Var. Т.е. если мы хотим создать динамичекий объект о время выполнения это выглядит так New Int I=10.

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

XC>Это какая-то попытка запихать инструкции (операторы языка) в парадигму ООП?
Да. Кстати, мои поздравления. Ты первый на планете, который дошел до такого уровня вопросов. Так и получается если мы хотим создать базу данных товара на складе, то определяем класс товара (Модель) , и просто создаем объекты-товары
Сlass Модель
{
Dim Int(Размер, Цена)

}
Модель1 Товар1 (Размер=25, Цена=45}
Модель1 Товар2 (Размер=27, Цена=56}

Модель1 Товарn (Размер=28, Цена=66}

И, заметь, это не программа! Это просто данные.

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

T>Идея такова: чтобы читать код на C/Perl нужно знать эти языки; для Python/Ruby часто достаточно знать английский.

Может быть... Но лично я не люблю, когда языки программирования пытаются приблизить к английскому. Получается неизменно паскаль.
Синтаксис — это важная составляющая языка, и ее важность в том, чтобы программист (именно программист, а не домохозяйка!) мог легко читать исходники на других языках, и быстро в них разбираться.
Есть традиционный, сложившийся синтаксис, не один десяток языков, на которых восклицательный знак это логическое отрицание. Это ни хорошо и ни плохо, это просто есть и все

Стандарт де-факто. Зачем придумывать что-то еще?

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

B>>>Разница между объектами и значениями (все они объекты мы здесь имеем ввиду объекты-объекты и объекты-значения) принципиальна. Объект может быть только один и равенство объектов означает что это один и тот же объект. Значений может быть сколько угодно и равенство значений это равенство всех свойств разных объектов значений. Отсюда и операция присвоения у объектов это копирование ссылки, а у значения копирование полностью объекта. Есть еще разница в том, что значение выражается текстом или цифрами. Например, Date=1 сентября 1995, Тор=65. Потому определение типов (они создают объекты-значения) оказывают влияние на лексический разбор. И т.д..Вообщем, есть разница, и тебе судить насколько она принципиальна.

B>Не причем здесь новизна. Это классические вещи. Только я четко разделил. Когда есть разные сущности то они и должны быть разными. Присвоение и передачу параметров, это понятно что можно сделать и так и так.Только это чревато. Но вот как с присваиванием быть? Разные знаки делать? Ведь очевидно что суть этих операций разная для класов и типов. А операцию равенства? Для объектов эта операция заключается в равенстве ссылок, а для значений в проверке значения. Вот ты изменил свойство в объекте, например, зарплату или должность.. Объект должен гарантировано остаться тем же самым. И совсем другое дело если ты в объекте-дате изменил месяц! Получился ДРУГОЙ ОБЪЕКТ! Одинаковых объектов-значений могут существовать тысячи одновременно, а объект один и навсегда.

В С++ есть операторы точка, стрелка, два двоеточия, для РАЗНЫХ случаев, но смысл один — "accessor", доступ к внутренностям составного объекта по имени. В C# и Java благополучно это убрали, и ИМХО правильно сделали.
А ты предлагаешь разделить абстракцию присваивания на две части. И бедные программеры опять будут думать "ну какой-же оператор здесь применить?"

XC>>Это какая-то попытка запихать инструкции (операторы языка) в парадигму ООП?
B>Рассказываю. Когда ты пишешь буквы они тоже объекты. Потом из букв сконструировал слово (в нашем примере For) так вот как слово это самостоятельный объект и другого класса чем буквы, т.е. со своими собственными свойствами. Если у букв есть шрифты, размер и прочее (кстати, я категорически против что б буквы имели свойство язык), а у слова свои свойства как у самостоятельного объекта воспринимаемого как единое целое а не то из чего оно состоит. Класс и свойства этого объекта (создание объекта For класса "Lexem" ) определяется при лексическом анализе. Как и все остальные лексемы. А уже при трансляции в синтаксическом анализаторе из последовательности лексем и знаков согласно синтаксису создается объект класса For. Да, это такой же объект. Вот и если речь идет о программе то создается объекты-инструкции. Это еще один тип объектов плюс к объектам-значениям.
B>Дальше совсем просто. Если мы хотим создать форму BB то так и пишем Form BB. Так в результате трансляции создастся объект этого класса.

ИМХО, ты как-то неуловимо путаешь этапы компиляции и выполнения программы. При лексическом анализе в классическом понимании этого слова не происходит ничего, кроме того что поток исходного текста программы разбивается на лексемы, просто для удобства дальнейшего синтаксического анализа.

B>А теперь проблема!
B>Int I=10 что создаст при трансляции? Обычно в языках в такой форме синтаксиса создается (скрытая от глаз) инструкция срабатывающая во время выполения (а не трансляции), и создающая динамически целую переменную где-то в выделеной области памяти.
B>У меня создается именно целое значение =10 в этом месте. Для того, что бы во время выполнения создать такое значение (или такие значения если это в классе и есть вариант одновременного вызова) необходимо иметь еще одну инструкцию которую необходимо применить к этому объекту для динамического создания. И эта инструкция есть. Даже три! New, Dim и Var. Т.е. если мы хотим создать динамичекий объект о время выполнения это выглядит так New Int I=10.

Не понял в чем проблема.
Ты предлагаешь 'int i=10' сделать объявлением константы, не порождающим никакого кода? А смысл? Чем это отличается от конструкции с макросами на том же си?

#define I 10
int i = I;

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

XC>Это какая-то попытка запихать инструкции (операторы языка) в парадигму ООП?

В Smalltalk давно запихали.

А топикстарер похоже бредит

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

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

B>>Не причем здесь новизна. Это классические вещи. Только я четко разделил. Когда есть разные сущности то они и должны быть разными. Присвоение и передачу параметров, это понятно что можно сделать и так и так.Только это чревато. Но вот как с присваиванием быть? Разные знаки делать? Ведь очевидно что суть этих операций разная для класов и типов. А операцию равенства? Для объектов эта операция заключается в равенстве ссылок, а для значений в проверке значения. Вот ты изменил свойство в объекте, например, зарплату или должность.. Объект должен гарантировано остаться тем же самым. И совсем другое дело если ты в объекте-дате изменил месяц! Получился ДРУГОЙ ОБЪЕКТ! Одинаковых объектов-значений могут существовать тысячи одновременно, а объект один и навсегда.

XC>В С++ есть операторы точка, стрелка, два двоеточия, для РАЗНЫХ случаев, но смысл один — "accessor", доступ к внутренностям составного объекта по имени. В C# и Java благополучно это убрали, и ИМХО правильно сделали.
XC>А ты предлагаешь разделить абстракцию присваивания на две части. И бедные программеры опять будут думать "ну какой-же оператор здесь применить?"
Не придумывай за меня. В этом смысле я предлагаю оставить один оператор присваивания, смысл которого будет зависить от классов объектов. Причем весьма логично. Но, дальше таки будет два оператора присваивания. Смысл их расскажу позже, по мере усваивания материала. С классами это не связано.

B>>Рассказываю. Когда ты пишешь буквы они тоже объекты. Потом из букв сконструировал слово (в нашем примере For) так вот как слово это самостоятельный объект и другого класса чем буквы, т.е. со своими собственными свойствами. Если у букв есть шрифты, размер и прочее (кстати, я категорически против что б буквы имели свойство язык), а у слова свои свойства как у самостоятельного объекта воспринимаемого как единое целое а не то из чего оно состоит. Класс и свойства этого объекта (создание объекта For класса "Lexem" ) определяется при лексическом анализе. Как и все остальные лексемы. А уже при трансляции в синтаксическом анализаторе из последовательности лексем и знаков согласно синтаксису создается объект класса For. Да, это такой же объект. Вот и если речь идет о программе то создается объекты-инструкции. Это еще один тип объектов плюс к объектам-значениям.
B>>Дальше совсем просто. Если мы хотим создать форму BB то так и пишем Form BB. Так в результате трансляции создастся объект этого класса.

XC>ИМХО, ты как-то неуловимо путаешь этапы компиляции и выполнения программы. При лексическом анализе в классическом понимании этого слова не происходит ничего, кроме того что поток исходного текста программы разбивается на лексемы, просто для удобства дальнейшего синтаксического анализа.
Так вот что-то же происходит! Лексемы таки образуются! А ведь это объекты! И не только для синтаксического анализа. Вполне реально для трансляции нам необходимо будет анализировать свойства этих объектов. Например, у меня нет требования уникальности имени. А для некоторых классов уникальнность только внутри класса. Да и текст от имен надо будет отличать. А это все в свойствах лексемы! Почему, например, нельзя одинм именем назвать и класс и объект? Ведь по положению в синтаксисе мы вполне можем разобраться. А если есть неоднозначность, то необходимо указать. Как? Да изменением свойств вот этой самой лексемы! В обычном языке один и тот же текст может являться и глаголом и существительным. Классом и объектом! Например: "Каждый мужчина должен построить дом...." здесь "дом" в смысле класса объектов. А в фразе "Вот дом в котором я живу." слово дом применяется как объект. И по английски "Cup of tee" и "Drink tea" tea- в первом случае объект, а во втором класс.
Короче лексемы нам очень даже нужны как объекты, и нужен доступ для редактирования (т.е. для изменения их свойств) и анализа свойств лексемы. Анализом, занимается, как ты и сказал, синтаксический анализатор. И, вообще, вдумайся. Ты же текст воспринимаешь не в буквах, а в лексемах. Ну, один в один как синтаксический анализатор.

B>>А теперь проблема!
B>>Int I=10 что создаст при трансляции? Обычно в языках в такой форме синтаксиса создается (скрытая от глаз) инструкция срабатывающая во время выполения (а не трансляции), и создающая динамически целую переменную где-то в выделеной области памяти.
B>>У меня создается именно целое значение =10 в этом месте. Для того, что бы во время выполнения создать такое значение (или такие значения если это в классе и есть вариант одновременного вызова) необходимо иметь еще одну инструкцию которую необходимо применить к этому объекту для динамического создания. И эта инструкция есть. Даже три! New, Dim и Var. Т.е. если мы хотим создать динамичекий объект о время выполнения это выглядит так New Int I=10.

XC>Не понял в чем проблема.
XC>Ты предлагаешь 'int i=10' сделать объявлением константы, не порождающим никакого кода? А смысл? Чем это отличается от конструкции с макросами на том же си?
XC>

XC>#define I 10
XC>int i = I;
XC>

Совершенно верно, 'int i=10' не порождает никакого кода (в Ладе), в том смысле как ты его понимаешь. Порождается объект с именем I класса Int со значением 10. И больше ничего. Потому что вот это присвоение (помнишь мы о двух присвоениях говорили?) присваивает значение 10 свойству Value объекта класса Int с именем I. Есть двоичное представление объекта, и вот там где в этом представлении должно находиться значение свойства Value будет находиться значение 10, а там где должно находиться имя объекта будет находиться значение I. Более того мы так и сохраним это значение или много таких значений которые можно и проще создать просто набрав числ "10". Имени не будет. А результат будет тот же. Теперь вспомни, что типы порождают объекты-значения и тем оказывают влияние на лексический анализ. Вот оно это влияние! Type Int влияет на лексический анализ так, что набрав значение "10" при лексическом анализе создается объект этого класса с набраным значением.
А вот такое вот присвоение
I:=10 перед тем как, создаст объект-значение 10 создаст ссылку (там тоже есть варианты адресации) на объект с именем I и сформирует объект-инструкцию которая при выполнении присвоит объекту по этой ссылке значение 10, хранящееся здесь же.

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

B>Так вот что-то же происходит! Лексемы таки образуются! А ведь это объекты! И не только для синтаксического анализа. Вполне реально для трансляции нам необходимо будет анализировать свойства этих объектов. Например, у меня нет требования уникальности имени. А для некоторых классов уникальнность только внутри класса. Да и текст от имен надо будет отличать. А это все в свойствах лексемы! Почему, например, нельзя одинм именем назвать и класс и объект? Ведь по положению в синтаксисе мы вполне можем разобраться. А если есть неоднозначность, то необходимо указать. Как? Да изменением свойств вот этой самой лексемы! В обычном языке один и тот же текст может являться и глаголом и существительным. Классом и объектом! Например: "Каждый мужчина должен построить дом...." здесь "дом" в смысле класса объектов. А в фразе "Вот дом в котором я живу." слово дом применяется как объект. И по английски "Cup of tee" и "Drink tea" tea- в первом случае объект, а во втором класс.
B>Короче лексемы нам очень даже нужны как объекты, и нужен доступ для редактирования (т.е. для изменения их свойств) и анализа свойств лексемы. Анализом, занимается, как ты и сказал, синтаксический анализатор. И, вообще, вдумайся. Ты же текст воспринимаешь не в буквах, а в лексемах. Ну, один в один как синтаксический анализатор.

Ты ОПРЕДЕЛЕННО путаешь процесс компиляции и процесс исполнения программы

Изучи как осуществляется процесс компиляции. Разберись с этапами.
Лексемы образуются при лексическом анализе. Это просто разбиение текста на кусочки, не более того! Каждому кусочку ставится в соответствие код типа из множества {Идентификатор, Число, Строка, Оператор, Разделитель, Комментарий}. И для операторов и ключевых слов — еще одно число, внутренний номер оператора/ключевого слова. Числа преобразуются в бинарную форму, строки преобразуются с учетом escape-последовательностей, комментарии и разделители выкидываются. И все!

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

В общем, почитай ту же книгу Дракона что-ли

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

XC>Было бы здорово, опять-таки, ПРИМЕРЫ по КАЖДОМУ пункту этого списка. Вот так — на твоем языке, а вот так — на C++/C#/Java. Сравнение реализаций, преимущества твоей реализации, недостатки существующей.

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

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

T>Извините, что вмешиваюсь, но недостаток восклицательного знака в Си очевиден: неинтуитивная семантика.
T>Вот сравните:

T>Ruby:
T>

T>if messages.empty?  # true - да, список пустой
T>  user.logout!      # "опасный" метод, модифицирует состояние объекта. Немного истерично, но в этом хотя бы есть смысл.
T>

А отрицание условия будет if !messages.empty?
Здесь Руби придерживается той же традиции.

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

XC>Ты ОПРЕДЕЛЕННО путаешь процесс компиляции и процесс исполнения программы

Может, он седьмой Перл делает. Недаром говорят only Perl can parse Perl...

XC>>4. Самое главное — в чем фишка-то?
B>Если б фишка была она я бы не вылезал с новым языком. Фишек там много. Основные, я вынес в первые три раздела. Это правила именования и формирования текста.

По-русски можно? Что это значит? Желательно на примерах

B>Правило объединения объектов в группы и реализация объектов. Т.е. правила создания объектов. Это основное.

Что это такое? На примере, пожалуйста.

B>Есть еще сильная вещь (обрати внимание) события. Это здорово облегчает программирование и стандартизирует взаимодействие между объектами.

Smalltalk, Erlang, Scala — уже есть. Если не изменяет память, то еще Go и в Node.js тоже есть

B>Кстати, позволяет создавать автоматы. Тоже интересная фича.

Автоматы позволяют любые языки. Некоторые еще и облегчают (gen_fsm из Erlang'а)

B>Ну, оператор, например, новый есть Swith.

Что это за оператор, что он делает, и зачем он нужен?

B> Операция обмена тоже новая фишка.

Что за операция обмена?

B>Распараллеливание с помощью групп..

Ээээ. Чего?

Распараллеливание: Erlang, Go

B>А выполнение групп с надстрочным значением?

Что такое группа с надстрочным значением?

B>Та много.. Вот хотя бы первые три концепции кто б осилил..

А ты бы хоть один пример по каждой из этих концепций привел

B>Не знаю где ты смотришь, но здесь http://files.rsdn.ru/91645/LadaNew.rar сравнительно свежая версия

Нет, чтобы выложить это на Google Code/GitHub/Bitbucket... Вопросов о свежести не возникало бы

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

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

B>>Так вот что-то же происходит! Лексемы таки образуются! А ведь это объекты! И не только для синтаксического анализа. Вполне реально для трансляции нам необходимо будет анализировать свойства этих объектов. Например, у меня нет требования уникальности имени. А для некоторых классов уникальнность только внутри класса. Да и текст от имен надо будет отличать. А это все в свойствах лексемы! Почему, например, нельзя одинм именем назвать и класс и объект? Ведь по положению в синтаксисе мы вполне можем разобраться. А если есть неоднозначность, то необходимо указать. Как? Да изменением свойств вот этой самой лексемы! В обычном языке один и тот же текст может являться и глаголом и существительным. Классом и объектом! Например: "Каждый мужчина должен построить дом...." здесь "дом" в смысле класса объектов. А в фразе "Вот дом в котором я живу." слово дом применяется как объект. И по английски "Cup of tee" и "Drink tea" tea- в первом случае объект, а во втором класс.
B>>Короче лексемы нам очень даже нужны как объекты, и нужен доступ для редактирования (т.е. для изменения их свойств) и анализа свойств лексемы. Анализом, занимается, как ты и сказал, синтаксический анализатор. И, вообще, вдумайся. Ты же текст воспринимаешь не в буквах, а в лексемах. Ну, один в один как синтаксический анализатор.

XC>Ты ОПРЕДЕЛЕННО путаешь процесс компиляции и процесс исполнения программы

XC>Изучи как осуществляется процесс компиляции. Разберись с этапами.
XC>Лексемы образуются при лексическом анализе. Это просто разбиение текста на кусочки, не более того! Каждому кусочку ставится в соответствие код типа из множества {Идентификатор, Число, Строка, Оператор, Разделитель, Комментарий}. И для операторов и ключевых слов — еще одно число, внутренний номер оператора/ключевого слова. Числа преобразуются в бинарную форму, строки преобразуются с учетом escape-последовательностей, комментарии и разделители выкидываются. И все!

XC>То, что ты описываешь, отдаленно напоминает описание процесса компиляции программы, при этом в твоем описании все этапы перемешаны совершенно немыслимым образом.
XC>Какое это отношение имеет к "новому языку программирования" — вообще непонятно.

XC>В общем, почитай ту же книгу Дракона что-ли

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

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

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

B>>А теперь проблема!
B>>Int I=10 что создаст при трансляции? Обычно в языках в такой форме синтаксиса создается (скрытая от глаз) инструкция срабатывающая во время выполения (а не трансляции), и создающая динамически целую переменную где-то в выделеной области памяти.
B>>У меня создается именно целое значение =10 в этом месте. Для того, что бы во время выполнения создать такое значение (или такие значения если это в классе и есть вариант одновременного вызова) необходимо иметь еще одну инструкцию которую необходимо применить к этому объекту для динамического создания. И эта инструкция есть. Даже три! New, Dim и Var. Т.е. если мы хотим создать динамичекий объект о время выполнения это выглядит так New Int I=10.

XC>Не понял в чем проблема.
XC>Ты предлагаешь 'int i=10' сделать объявлением константы, не порождающим никакого кода? А смысл? Чем это отличается от конструкции с макросами на том же си?
XC>

XC>#define I 10
XC>int i = I;
XC>

Совершенно верно. Int i=10 или просто 10 порождают один и тот же объект. С именем или без. А вот Dim Int I=10 это уже порождает целое число с динамическим размещением. Я ж говорю что на моем языке можно не только программы писать. Но и любые документы. Таким образом for i=10 to 20 порождает объект-инструкцию класса For. Хотя можно и к нему применить объект Dim...

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

B>>Так там есть примеры.
B>>Могу здесь по быстрому. Но, все нюансы (а они не нюансы) будет сложно. Вау.. Здесь не возможно. Скобки и надстрочные значения я здесь не смогу привести. Ну, почему бы не посмотреть примеры в документе?

XC>Еще раз: в документе непонятно. Напиши hello world на Lada, и еще пару примеров: реализацию двусвязного списка или очереди, сортировку какую-нибудь... С комментариями, и — повторюсь — со СРАВНЕНИЕМ твоей реализации и существующих.

XC>Я вот дошел до первого примера и уже в ступоре

XC>

XC>For I=30 To N {J +:= 1}
XC>

XC>им дальше по тексту
XC>

В результате работы синтаксического анализатора из последовательности лексем будет создан объект класса For с именем I, который в свою очередь может нуждаться в реализации

XC>а я то думал это обычный цикл с параметром...

XC>Это какая-то попытка запихать инструкции (операторы языка) в парадигму ООП?
Да. Только почему "запихать"? Так оно и есть..Объект-инструкция..
А почему бы и нет?

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

M>А ты бы хоть один пример по каждой из этих концепций привел
Здесь здесь посмотри. Там и подробней и с примерами

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

B>>Не знаю где ты смотришь, но здесь http://files.rsdn.ru/91645/LadaNew.rar сравнительно свежая версия

M>Нет, чтобы выложить это на Google Code/GitHub/Bitbucket... Вопросов о свежести не возникало бы
Ну, извини. Не могу же я быть везде.. Скромность..

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

> Я буду отвечать на вопросы.

Я так и не понял, прочитав тред и (бегло) LadaNew. Чем оно облегчает мне жизнь? Что в нём есть такое, что я хотел бы использовать этот язык а не явы, питоны, скалы и груви, руби, эрланги, лиспы?

Что там с обобщенным программированием? Все большие примеры(та же сортировка) явно задают тип аля Integer.

Игнорируя воду. Мы можем увидеть не совсем тривиальный кусок кода? Крестики-нолики, например.
Ну или хотя бы сравнение в стиле "вот код на окамле, вот аналог на ладе"

B>>>Не знаю где ты смотришь, но здесь http://files.rsdn.ru/91645/LadaNew.rar сравнительно свежая версия

M>>Нет, чтобы выложить это на Google Code/GitHub/Bitbucket... Вопросов о свежести не возникало бы
B>Ну, извини. Не могу же я быть везде.. Скромность..

Что значит везде? Достаточно выложить код один раз на тот же GitHub и не требовать, чтобы все следили за тем, где, когда и кем выложен новый .rar-файл

M>>А ты бы хоть один пример по каждой из этих концепций привел
B>Здесь здесь посмотри. Там и подробней и с примерами

Там есть многостраничные описания. Причем использующие не общепринятые названия, а собственноручно придуманные термины. Хочется, чтобы было в таком стиле:

У нас есть такая-то задача...

Пример решения ее в Lada...

Это лучше, чем аналогичное решение в других языках потому что...

Потому что «пример» в том стиле, что используется в документе:

Пример 1.3. Именование объекта типа Integer присвоением значения Ширина свойству Name.

10 ‘ Name=: «Ширина» ’

Напоминает только Кэролловское:

— ...Заглавие этой песни называется "Пуговки для сюртуков".
— Вы хотите сказать — песня так называется? — спросила Алиса, стараясь заинтересоваться песней.
— Нет, ты не понимаешь, — ответил нетерпеливо Рыцарь. — Это заглавие так называется. А песня называется "Древний старичок".
— Мне надо было спросить: это у песни такое заглавие? — поправилась Алиса.
— Да нет! Заглавие совсем другое. "С горем пополам!" Но это она только так называется!
— А песня эта какая? — спросила Алиса в полной растерянности.
— Я как раз собирался тебе об этом сказать. "Сидящий на стене"! Вот какая это песня! Музыка собственного изобретения!

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

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

>> Я буду отвечать на вопросы.

M>Я так и не понял, прочитав тред и (бегло) LadaNew. Чем оно облегчает мне жизнь? Что в нём есть такое, что я хотел бы использовать этот язык а не явы, питоны, скалы и груви, руби, эрланги, лиспы?

M>Что там с обобщенным программированием? Все большие примеры(та же сортировка) явно задают тип аля Integer.

M>Игнорируя воду. Мы можем увидеть не совсем тривиальный кусок кода? Крестики-нолики, например.
M>Ну или хотя бы сравнение в стиле "вот код на окамле, вот аналог на ладе"
Есть примеры.. Я сделаю подборочку типа Хелло ворд..Для быстрого вхождения. Работу уже начал, но она не закончена. Пока можно обойтись примерами теми что там есть. Особенно в разделе где события может быть интересно.. И где реализация определений (там очень отдаленно возможности лиспа). Логическое программирование не помню есть ли там примеры.. но там похоже на Пролог. Только синтаксис свой.
Сори. Не все сразу..

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

B>>>>Не знаю где ты смотришь, но здесь http://files.rsdn.ru/91645/LadaNew.rar сравнительно свежая версия

M>>>Нет, чтобы выложить это на Google Code/GitHub/Bitbucket... Вопросов о свежести не возникало бы
B>>Ну, извини. Не могу же я быть везде.. Скромность..

M>Что значит везде? Достаточно выложить код один раз на тот же GitHub и не требовать, чтобы все следили за тем, где, когда и кем выложен новый .rar-файл
Так выложи. Я разрешаю.. Только ссылку дашь.. Я не в курсе где это.. Кстати, на этом сайте я тоже так появился. Только тут выложили материал меня не спрашивая, а потом дали ссылку

B>>>>>Не знаю где ты смотришь, но здесь http://files.rsdn.ru/91645/LadaNew.rar сравнительно свежая версия

M>>>>Нет, чтобы выложить это на Google Code/GitHub/Bitbucket... Вопросов о свежести не возникало бы
B>>>Ну, извини. Не могу же я быть везде.. Скромность..

M>>Что значит везде? Достаточно выложить код один раз на тот же GitHub и не требовать, чтобы все следили за тем, где, когда и кем выложен новый .rar-файл
B>Так выложи. Я разрешаю.. Только ссылку дашь.. Я не в курсе где это.. Кстати, на этом сайте я тоже так появился. Только тут выложили материал меня не спрашивая, а потом дали ссылку

Зачем это делать мне? Ты автор текста, не я. Или ты везде будешь давать ссылки на документы типа LadaNew.rar, LadaNew2.rar, LadaNew_Last.rar, LadaNew_Last_FinalVersion.rar и т.п.? А потом говорить следющее: http://rsdn.ru/forum/philosophy/3900646.1.aspx

Не знаю где ты смотришь, но здесь http://files.rsdn.ru/91645/LadaNew.rar сравнительно свежая версия

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

Насчет не в курсе, где это, у меня в сообщении достаточно информации, чтобы найти: github.com, bitbucket.org, code.google.com

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

M>>>А ты бы хоть один пример по каждой из этих концепций привел
B>>Здесь здесь посмотри. Там и подробней и с примерами

M>Там есть многостраничные описания. Причем использующие не общепринятые названия, а собственноручно придуманные термины. Хочется, чтобы было в таком стиле:
M>

M>У нас есть такая-то задача...

M>Пример решения ее в Lada...

M>Это лучше, чем аналогичное решение в других языках потому что...

M>Потому что «пример» в том стиле, что используется в документе:
M>

M>Пример 1.3. Именование объекта типа Integer присвоением значения Ширина свойству Name.

M>10 ‘ Name=: «Ширина» ’

M>Напоминает только Кэролловское:
M>

M>— ...Заглавие этой песни называется "Пуговки для сюртуков".
M>— Вы хотите сказать — песня так называется? — спросила Алиса, стараясь заинтересоваться песней.
M>— Нет, ты не понимаешь, — ответил нетерпеливо Рыцарь. — Это заглавие так называется. А песня называется "Древний старичок".
M>— Мне надо было спросить: это у песни такое заглавие? — поправилась Алиса.
M>— Да нет! Заглавие совсем другое. "С горем пополам!" Но это она только так называется!
M>— А песня эта какая? — спросила Алиса в полной растерянности.
M>— Я как раз собирался тебе об этом сказать. "Сидящий на стене"! Вот какая это песня! Музыка собственного изобретения!

Кэролл не был глуп. А тема насчет имени объекта очень любопытная.. Понятно, что имя это значение некоторого свойства объекта. Так же понятно, что значение этого свойства где-то присваивается. Как правило, в момент создания объекта. До этого момента имя (как и вся программа) в общем случае является текстом. Но текст и имя имя это разные вещи. Это очевидно когда мы, например, отправляем на печать текст, то отправляем текст, а по имени мы отправляем значение объекта с этим именем. Это различие интуитивно очевидно. Так текст может иметь вложения. Классический пример это прямая речь. Хотя то, что мы отправляем на печать, тоже семантически отделено от текста программы и имеет собственную семантическую ценность будучи выведеной на печать. Я это подчеркиваю так настырно, потому как операторы у меня тоже объекты и могут иметь имена и оператор, например Exit указывает имя объекта-оператора (а может и класса) из которого необходимо выйти. Получается например такая картина.
For i=0 to n
...
Exit I

То в операторе Exit I-это имя оператора For, а не имя переменной.

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

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

M>Насчет не в курсе, где это, у меня в сообщении достаточно информации, чтобы найти: github.com, bitbucket.org, code.google.com
Тогда все равно сори.. Я этим не позже займусь

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

M>Я так и не понял, прочитав тред и (бегло) LadaNew. Чем оно облегчает мне жизнь? Что в нём есть такое, что я хотел бы использовать этот язык а не явы, питоны, скалы и груви, руби, эрланги, лиспы?

M>Что там с обобщенным программированием? Все большие примеры(та же сортировка) явно задают тип аля Integer.

M>Игнорируя воду. Мы можем увидеть не совсем тривиальный кусок кода? Крестики-нолики, например.
M>Ну или хотя бы сравнение в стиле "вот код на окамле, вот аналог на ладе"

Тут целая толпа ждет хоть малейшего примера, который хоть что-то показывает. В ответ только отсыл на простыню с водой(еще и в кривом доке в архиве) и утверждения, что это платформа для всего-всего-всего. Но при этом ни малейшего примерчика, который бы показал преимущества перед любой существующей платформой — увы, нет.

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

Что-то не понял, может для столь инновационного языка надо начать с разработки новаторской операционной системы? Зачем же держать себя в рамках

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

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

A>Что-то не понял, может для столь инновационного языка надо начать с разработки новаторской операционной системы? Зачем же держать себя в рамках

?

Да ну давай, какая же новаторская ОС на старом железе? С кремния начинать надо

?
Может... Займись.

M>>Напоминает только Кэролловское:
M>>

M>>— ...Заглавие этой песни называется "Пуговки для сюртуков".
M>>— Вы хотите сказать — песня так называется? — спросила Алиса, стараясь заинтересоваться песней.
M>>— Нет, ты не понимаешь, — ответил нетерпеливо Рыцарь. — Это заглавие так называется. А песня называется "Древний старичок".
M>>— Мне надо было спросить: это у песни такое заглавие? — поправилась Алиса.
M>>— Да нет! Заглавие совсем другое. "С горем пополам!" Но это она только так называется!
M>>— А песня эта какая? — спросила Алиса в полной растерянности.
M>>— Я как раз собирался тебе об этом сказать. "Сидящий на стене"! Вот какая это песня! Музыка собственного изобретения!

B>Кэролл не был глуп. А тема насчет имени объекта очень любопытная.. Понятно, что имя это значение некоторого свойства объекта. Так же понятно, что значение этого свойства где-то присваивается. Как правило, в момент создания объекта. До этого момента имя (как и вся программа) в общем случае является текстом. Но текст и имя имя это разные вещи. Это очевидно когда мы, например, отправляем на печать текст, то отправляем текст, а по имени мы отправляем значение объекта с этим именем. Это различие интуитивно очевидно. Так текст может иметь вложения. Классический пример это прямая речь. Хотя то, что мы отправляем на печать, тоже семантически отделено от текста программы и имеет собственную семантическую ценность будучи выведеной на печать. Я это подчеркиваю так настырно, потому как операторы у меня тоже объекты и могут иметь имена и оператор, например Exit указывает имя объекта-оператора (а может и класса) из которого необходимо выйти. Получается например такая картина.
B>For i=0 to n
B>...
B>Exit I

B>То в операторе Exit I-это имя оператора For, а не имя переменной.

И? Что мне, как программисту, это дает?

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

M>>Насчет не в курсе, где это, у меня в сообщении достаточно информации, чтобы найти: github.com, bitbucket.org, code.google.com
B>Тогда все равно сори.. Я этим не позже займусь

А по-русски?

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

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

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

A>>Что-то не понял, может для столь инновационного языка надо начать с разработки новаторской операционной системы? Зачем же держать себя в рамках

?

К>Да ну давай, какая же новаторская ОС на старом железе? С кремния начинать надо

Да что то я неглубоко капнул тему, действительно, какие нафик языки и операционки, когда соверменным железом пользоваться совершенно невозможно!

ЗЫ Раньше было модно начинать обсуждение платформы с GC, почему в данной теме столь прогрессивной вопрос остался за бортом

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

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

CU>>ну теперь я уже принципиально не буду скачивать архив

E__>Я даже скачал. Но прочесть так и не смог — у меня файл растаращило до совершенно нечитабельного вида.
Зато можно представить каким космическим будет язык, если его описалово половина народа не смога открыть, а те что открыли не смогли понять!

XC>

XC>func1("Hello world"); // void func1(char *s);
XC>

XC>но нельзя
XC>

XC>func2({100,200,300}); // void func2(int *a);
XC>

C99:

void fun(int *a)
{
}

int main()
{
  fun((int[3]){100,200,300});
}

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

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

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

B>>>Пока не существующему. Внеси свою лепту. Я не обижусь

К>>А про лепту — почему не видно ссылки на розиторий на github/Google Code/etc.?
B>Не задрачивай.. Если хочешь сам делай.. Кстати, и на этот сайт я попал не по собственному желанию.. Кто-то разместил здесь мои материалы, причем без моего согласия и под моим ником. Но, потом дал ссылку и пароль..Так я здесь появился..

У вас раздвоение личности?

Здравствуйте, batu, Вы писали:
B>С холодильниками будут проблемы. А указаными задачами очень даже справляется. И удобнее чем в частности XML справляестся с единственной задачей. Если интересно, то укажу на принципиальные недостатки XML

Про xml мы всё знаем, а вот говорить про то, с чем отлично справляется ваш язык, аналогично рассуждению, что было бы, если бы у вас было три ноги четыре руки и вы жили на дне океана. Где технологическое демо или хотя бы законченные примеры показывающие с чем он там потрясающе справляется.

XC>Ты ОПРЕДЕЛЕННО путаешь процесс компиляции и процесс исполнения программы

XC>Изучи как осуществляется процесс компиляции. Разберись с этапами.
Для разработки инновационного языка нужен новый подход, придумали тоже мне всякий синтаксический анализ, лексический, грамматики, терминологию всякую дурацкую, пойди разберись с ней... Лучше вот взять и зафигачить всё по новому, по своему!

Здравствуйте, batu, Вы писали:
XC>>В общем, почитай ту же книгу Дракона что-ли

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

Пока я набивал это топикастер меня опередил

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

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

VD>>>С виду идеи очень похожие — много слов, мал конкретики.
B>>Что именно интересует?

VD>Результат.
Создаётся ненавязчивое впечатление, что за столь увлекательным процессом разработки прогрессивнейшего языка автор окончательно потерял интерес к результату

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

B>Хотелось заменить все языки одним. Фактически получилось два. Один TLL его можно назвать теговым. Каждый тег-это объект. Второй язык высокого уровня LADA, однако существует взаимно-однозначное соответствие этих языков. Потому можно считать TLL ассемлером LADA. Понятно, что для работы этих языков необходима виртуальная машина, но об этом позже.
А почему бы вместо непонятного TLL не задействовать звучное название KALINA или GAZEL

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

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

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

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

B>>>>Пока не существующему. Внеси свою лепту. Я не обижусь

К>>>А про лепту — почему не видно ссылки на розиторий на github/Google Code/etc.?
B>>Не задрачивай.. Если хочешь сам делай.. Кстати, и на этот сайт я попал не по собственному желанию.. Кто-то разместил здесь мои материалы, причем без моего согласия и под моим ником. Но, потом дал ссылку и пароль..Так я здесь появился..

A>У вас раздвоение личности?
Льстишь?

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

M>И? Что мне, как программисту, это дает?
Ничего, кроме понимания.

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

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

M>>>Насчет не в курсе, где это, у меня в сообщении достаточно информации, чтобы найти: github.com, bitbucket.org, code.google.com
B>>Тогда все равно сори.. Я этим не позже займусь

M>А по-русски?
Ашибка редактирования. Частица не лишняя. Правильно так. "Я этим позже займусь"

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

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

B>>Хотелось заменить все языки одним. Фактически получилось два. Один TLL его можно назвать теговым. Каждый тег-это объект. Второй язык высокого уровня LADA, однако существует взаимно-однозначное соответствие этих языков. Потому можно считать TLL ассемлером LADA. Понятно, что для работы этих языков необходима виртуальная машина, но об этом позже.
A>А почему бы вместо непонятного TLL не задействовать звучное название KALINA или GAZEL

?
А почему авиатор предлагает автомобильное? Предложи авиационное

Да по фигу название. Во всяком случае пока.

M>>И? Что мне, как программисту, это дает?
B>Ничего, кроме понимания.

Понимания чего?

Можно еще раз.

Задачу.
Как она решается в Ладе
Чем это лучше других решений на других языках

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

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

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

B>>>Хотелось заменить все языки одним. Фактически получилось два. Один TLL его можно назвать теговым. Каждый тег-это объект. Второй язык высокого уровня LADA, однако существует взаимно-однозначное соответствие этих языков. Потому можно считать TLL ассемлером LADA. Понятно, что для работы этих языков необходима виртуальная машина, но об этом позже.
A>>А почему бы вместо непонятного TLL не задействовать звучное название KALINA или GAZEL

?
B>А почему авиатор предлагает автомобильное? Предложи авиационное

Да по фигу название. Во всяком случае пока.
Почему-то LADA вызывает такие ассоциации

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

M>>>И? Что мне, как программисту, это дает?
B>>Ничего, кроме понимания.

M>Понимания чего?

M>Можно еще раз.

M>Задачу.
M>Как она решается в Ладе
M>Чем это лучше других решений на других языках.
Вот, например, мне часто приходится анализировать текст. При этом постоянно приходится анализировать на конец текста. Или конец файла. При редактировании программы частенько бывают ошибки связаные с отсутствием этих проверок. Если оформить конец текста или конец файла как событие, то можно один раз написать обработку этого события и забыть про эти проверки напрочь.
Делается это так.

Пример 10.6. Определение события EndText с двумя связями.

Dim Integer Len: ' Длина текста
Dim Integer Ind ' Индекс проверяемого символа
Exp Boolean EndE=(Len=Ind): ' Логическое выражение
New Event EndText ' Формирование события
{Condition=:EndE
Connection.Add [|Ind.Chang, Len.Change]
Event: =MsgBox(“Конец текста”)
}

LEN-Длина
Ind-Индекс
Вместо процедуры просто вывод сообщения

M>>>>И? Что мне, как программисту, это дает?
B>>>Ничего, кроме понимания.

M>>Понимания чего?

M>>Можно еще раз.

M>>Задачу.
M>>Как она решается в Ладе
M>>Чем это лучше других решений на других языках.
B>Вот, например, мне часто приходится анализировать текст. При этом постоянно приходится анализировать на конец текста. Или конец файла. При редактировании программы частенько бывают ошибки связаные с отсутствием этих проверок. Если оформить конец текста или конец файла как событие, то можно один раз написать обработку этого события и забыть про эти проверки напрочь.
B>Делается это так.

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

B>Dim Integer Len:                                              ' Длина текста
B>Dim Integer Ind                                                ' Индекс проверяемого символа
B>Exp Boolean EndE=(Len=Ind):                        ' Логическое выражение
B>New Event EndText                                         ' Формирование события
B> {Condition=:EndE
B>   Connection.Add [|Ind.Chang, Len.Change]
B>      Event: =MsgBox(“Конец текста”)
B> }
B>

B>LEN-Длина
B>Ind-Индекс
B>Вместо процедуры просто вывод сообщения

И? Чем это лучше существующих решений?

using (StreamReader sr = new StreamReader(path)) 
{
    while (sr.Peek() >= 0) 
    {
        Console.Write((char)sr.Read());
    }
}

inputStream = new FileReader("xanadu.txt");

int c;
while ((c = inputStream.read()) != -1) {
    //что-то там делаем
}

и т.п.

Не говоря уже о том, что длина входящих данных нам может быть заранее неизвестна.

PS. Для оформления кода есть тэг [code]

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

M>>>И? Что мне, как программисту, это дает?
B>>Ничего, кроме понимания.

M>Понимания чего?

M>Можно еще раз.

M>Задачу.
M>Как она решается в Ладе
M>Чем это лучше других решений на других языках
Так же удачно использовать механизм событий когда есть необходимость анализировать много условий и в разных местах. Например, при моделировании фунционирования предприятия. Зачастую эти условия и зависимости проще сформулировать в терминах событий и обрабатывать как процедуры обработки событий. Это и надежней будет.

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

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

B>>Dim Integer Len:                                              ' Длина текста
B>>Dim Integer Ind                                                ' Индекс проверяемого символа
B>>Exp Boolean EndE=(Len=Ind):                        ' Логическое выражение
B>>New Event EndText                                         ' Формирование события
B>> {Condition=:EndE
B>>   Connection.Add [|Ind.Chang, Len.Change]
B>>      Event: =MsgBox(“Конец текста”)
B>> }
B>>

B>>LEN-Длина
B>>Ind-Индекс
B>>Вместо процедуры просто вывод сообщения

M>И? Чем это лучше существующих решений?
M>

M>inputStream = new FileReader("xanadu.txt");

M>int c;
M>while ((c = inputStream.read()) != -1) {
M>    //что-то там делаем
M>}
M>

M>и т.п.

Это лучше вашего варианта тем, что все эти проверки выполняются неявно, не в основном цикле чтения.

Примерно так же, как использование декларативных сканнеров, например lex, лучше чем

while ((c = input.read()) != -1) {
  if c == 'G' {
    if (c = input.read()) == 'E' {
      if (c = input.read()) == 'T' {
        return token.Get;
      }
      ...
    }
    ...
  }
  ...
}

На самом деле, про события это одна из немногих вменяемых идей в его языке, просто он её (и ни одну другую) объяснить по русски не может.

M>Не говоря уже о том, что длина входящих данных нам может быть заранее неизвестна.

Тогда он повесил бы обработчик на read() == -1.

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

T>Это лучше вашего варианта тем, что все эти проверки выполняются неявно, не в основном цикле чтения.

Рекомендую (хотябы для ознакомления) The Zen of Python, а для данного случая — 2-ю строчку оттуда.

T>>Это лучше вашего варианта тем, что все эти проверки выполняются неявно, не в основном цикле чтения.

К>Рекомендую (хотябы для ознакомления) The Zen of Python, а для данного случая — 2-ю строчку оттуда.

Про сканеры пример пропущен? Или такое explicit тоже better?

M>>>>И? Что мне, как программисту, это дает?
B>>>Ничего, кроме понимания.

M>>Понимания чего?

M>>Можно еще раз.

M>>Задачу.
M>>Как она решается в Ладе
M>>Чем это лучше других решений на других языках
B>Так же удачно использовать механизм событий когда есть необходимость анализировать много условий и в разных местах. Например, при моделировании фунционирования предприятия. Зачастую эти условия и зависимости проще сформулировать в терминах событий и обрабатывать как процедуры обработки событий. Это и надежней будет.

Им'я с'естра, им'я! То есть примеры!

var store = new Ext.JsonStore({
    url: '/',
    // другие параметры
});


store.on('load', function(){ /* делаем что-то */ });

Это — Javascript с фреймворком ExtJS. То есть чем конкретно лучше Лада, так и не понятно

Тут, правда, добрые люди объяснили. Но это все равно достижимо и выполнимо во многих языках.

Здравствуйте, batu, Вы писали:
B>Вот, например, мне часто приходится анализировать текст. При этом постоянно приходится анализировать на конец текста. Или конец файла. При редактировании программы частенько бывают ошибки связаные с отсутствием этих проверок. Если оформить конец текста или конец файла как событие, то можно один раз написать обработку этого события и забыть про эти проверки напрочь.
Похоже на то, как сделаны sax-парсеры xml. В принципе, ничего не мешает такое же, как у тебя, апи иметь в другом языке.

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

M>>>Как она решается в Ладе
M>>>Чем это лучше других решений на других языках.
B>>Вот, например, мне часто приходится анализировать текст. При этом постоянно приходится анализировать на конец текста. Или конец файла. При редактировании программы частенько бывают ошибки связаные с отсутствием этих проверок. Если оформить конец текста или конец файла как событие, то можно один раз написать обработку этого события и забыть про эти проверки напрочь.
B>>Делается это так.

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

B>>Dim Integer Len:                                              ' Длина текста
B>>Dim Integer Ind                                                ' Индекс проверяемого символа
B>>Exp Boolean EndE=(Len=Ind):                        ' Логическое выражение
B>>New Event EndText                                         ' Формирование события
B>> {Condition=:EndE
B>>   Connection.Add [|Ind.Chang, Len.Change]
B>>      Event: =MsgBox(“Конец текста”)
B>> }
B>>

B>>LEN-Длина
B>>Ind-Индекс
B>>Вместо процедуры просто вывод сообщения

M>И? Чем это лучше существующих решений?
M>

M>using (StreamReader sr = new StreamReader(path)) 
M>{
M>    while (sr.Peek() >= 0) 
M>    {
M>        Console.Write((char)sr.Read());
M>    }
M>}
M>

M>inputStream = new FileReader("xanadu.txt");

M>int c;
M>while ((c = inputStream.read()) != -1) {
M>    //что-то там делаем
M>}
M>

M>и т.п.

M>Не говоря уже о том, что длина входящих данных нам может быть заранее неизвестна.

M>PS. Для оформления кода есть тэг [code]
Длина в моем варианте не только не известна, но и может изменяться. Но, это не главное. У тебя просто цикл и ты проверяешь в одном месте. А если в результате анализа входящей информации надо поступать по разному, т.е. проверка необходима в разных ветках и местах (их может быть и 20-30), то ее там и надо делать. Когда отлаживаешь программу можно не уследить за логикой, или нечаянно удалишь эту проверку, то могут возникнуть проблемы. Оформив событием мы решаем проблему с проверкой раз и навсегда. Потому как при возникновении события оно будет всегда обработано. Вот в этом и разница. Ну, и поступая таким образом мы упрощаем логику самого анализа вынося какие-то повторяющиеся ( в силу возможного возникновения в разных местах) проверки можно просто вынести как бы за рамки программы.

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

T>>>Это лучше вашего варианта тем, что все эти проверки выполняются неявно, не в основном цикле чтения.

К>>Рекомендую (хотябы для ознакомления) The Zen of Python, а для данного случая — 2-ю строчку оттуда.

T>Про сканеры пример пропущен? Или такое explicit тоже better?

Не считаю, что сканеры имеют какое-либо отношение к нарисованному выше batu "коду".

T>>>>Это лучше вашего варианта тем, что все эти проверки выполняются неявно, не в основном цикле чтения.

К>>>Рекомендую (хотябы для ознакомления) The Zen of Python, а для данного случая — 2-ю строчку оттуда.

T>>Про сканеры пример пропущен? Или такое explicit тоже better?

К>Не считаю, что сканеры имеют какое-либо отношение к нарисованному выше batu "коду".

Ну на его событиях несложно построить сканер. Я конечно, не буду пытаться написать пример на LADA

но суть будет похожа на lex: правила матчинга лексем отдельно, проход по файлу отдельно.

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

T>На самом деле, про события это одна из немногих вменяемых идей в его языке, просто он её (и ни одну другую) объяснить по русски не может.

M>>Не говоря уже о том, что длина входящих данных нам может быть заранее неизвестна.

T>Тогда он повесил бы обработчик на read() == -1.

Спасибо. Я действительно плохо объясняю. Внутри себя в голове есть и там все понятно.. Я постоянно удивляюсь как можно не понять очевидные вещи. Не согласен что это единственная вменяемая вещь. Это самая легкообъясняемая. Потому я просто иногда молчу в тряпочку. Как например, про двойственную природу представления объекта. Императивную и логическую. Для не знакомых с прологом это вообще трудно объяснить. Идея в том, что бы использовать логическую интерпретацию вместо вычислений. И синтаксис простой.. То же логическое выражение со знаком вопроса пзапускает интерпретацию. А каждый объект может иметь две реализации. Как обычно в фигурных скобках императивную и в логических скобках логическую.
Потом сам принцип реализации объектов не только входит в единые правила группирования объктов (использование скобок), и значительно упрощает и синтакис языка и изучение. Да и виртуальная машина получается довольно простая. Я не говорю уже про новые возможности, повялющиеся при таких единых правилах. Уменьшается количество сущностей необходимых для понимания. Фактически 6 классов могут определить и виртуальную машину и синтаксис и лексику языка. Но, вот что б так просто получилось надо так сложно объяснять.. Потому я остановлюсь. Все равно нагрузил... надеюсь общими усилиями вырулится. Заранее всем благодарен

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

MC>Здравствуйте, batu, Вы писали:
B>>Вот, например, мне часто приходится анализировать текст. При этом постоянно приходится анализировать на конец текста. Или конец файла. При редактировании программы частенько бывают ошибки связаные с отсутствием этих проверок. Если оформить конец текста или конец файла как событие, то можно один раз написать обработку этого события и забыть про эти проверки напрочь.
MC>Похоже на то, как сделаны sax-парсеры xml. В принципе, ничего не мешает такое же, как у тебя, апи иметь в другом языке.
Можно. Но не так же. И вообще парсеры у меня включены в систему как единое целое

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

T>>>>>Это лучше вашего варианта тем, что все эти проверки выполняются неявно, не в основном цикле чтения.

К>>Не считаю, что сканеры имеют какое-либо отношение к нарисованному выше batu "коду".

T>Ну на его событиях несложно построить сканер. Я конечно, не буду пытаться написать пример на LADA

но суть будет похожа на lex: правила матчинга лексем отдельно, проход по файлу отдельно.

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

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

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

M>>>>Как она решается в Ладе
M>>>>Чем это лучше других решений на других языках.
B>>>Вот, например, мне часто приходится анализировать текст. При этом постоянно приходится анализировать на конец текста. Или конец файла. При редактировании программы частенько бывают ошибки связаные с отсутствием этих проверок. Если оформить конец текста или конец файла как событие, то можно один раз написать обработку этого события и забыть про эти проверки напрочь.
B>>>Делается это так.

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

B>>>Dim Integer Len:                                              ' Длина текста
B>>>Dim Integer Ind                                                ' Индекс проверяемого символа
B>>>Exp Boolean EndE=(Len=Ind):                        ' Логическое выражение
B>>>New Event EndText                                         ' Формирование события
B>>> {Condition=:EndE
B>>>   Connection.Add [|Ind.Chang, Len.Change]
B>>>      Event: =MsgBox(“Конец текста”)
B>>> }
B>>>

B>>>LEN-Длина
B>>>Ind-Индекс
B>>>Вместо процедуры просто вывод сообщения

M>>И? Чем это лучше существующих решений?
M>>

M>>using (StreamReader sr = new StreamReader(path)) 
M>>{
M>>    while (sr.Peek() >= 0) 
M>>    {
M>>        Console.Write((char)sr.Read());
M>>    }
M>>}
M>>

M>>

M>>inputStream = new FileReader("xanadu.txt");

M>>int c;
M>>while ((c = inputStream.read()) != -1) {
M>>    //что-то там делаем
M>>}
M>>

M>>и т.п.

M>>Не говоря уже о том, что длина входящих данных нам может быть заранее неизвестна.

M>>PS. Для оформления кода есть тэг [code]
B> Длина в моем варианте не только не известна, но и может изменяться. Но, это не главное. У тебя просто цикл и ты проверяешь в одном месте. А если в результате анализа входящей информации надо поступать по разному, т.е. проверка необходима в разных ветках и местах (их может быть и 20-30), то ее там и надо делать.

Ну так и делается

Никто не требует, чтобы все было внутри цикла

И никто не собирается писать цикл длинной 10 000 строчек.

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

Когда занимаешься отладкой программы, можно не уследить за логикой или нечаянно удалить это событие. Могут возникнуть проблемы. Оформив это циклом, мы четко и явно прописываем, что именно мы делаем

B>Потому как при возникновении события оно будет всегда обработано. Вот в этом и разница. Ну, и поступая таким образом мы упрощаем логику самого анализа вынося какие-то повторяющиеся ( в силу возможного возникновения в разных местах) проверки можно просто вынести как бы за рамки программы.

И это реализуется в существующих языках программирования и существующих программах

Если не ошибаюсь, именно это называется Событийно-ориентированное программирование. Пример, как самый простейший — в Node.js

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

M>Ну так и делается

Никто не требует, чтобы все было внутри цикла

И никто не собирается писать цикл длинной 10 000 строчек.

M>Когда занимаешься отладкой программы, можно не уследить за логикой или нечаянно удалить это событие. Могут возникнуть проблемы. Оформив это циклом, мы четко и явно прописываем, что именно мы делаем

Видимо у меня не получается объяснить. Можешь представить что тебе нужно написать программу моделирующую деятельность предприятия или управление государством? Вот если кто-то уволится, то кем, за что..по каким законам и приказам. Какие действия после увольнения. Кто уполномочен и какие процедуры при найме нового человека.. И так по всей деятельности предпрития. Задолбаешься в лоб писать. А потом могут поменяться инструкции и за ним появится новая схема управления. А если разбить на события, то писать прогу, и апгретить будет значительно легче. События сами позацепляются за что нужно, да еще и можно протестить на полноту и прочую дребдень.

B>>Потому как при возникновении события оно будет всегда обработано. Вот в этом и разница. Ну, и поступая таким образом мы упрощаем логику самого анализа вынося какие-то повторяющиеся ( в силу возможного возникновения в разных местах) проверки можно просто вынести как бы за рамки программы.

M>И это реализуется в существующих языках программирования и существующих программах

Если не ошибаюсь, именно это называется Событийно-ориентированное программирование. Пример, как самый простейший — в Node.js
Я не претендую на уникальность. На системность да.. Есть еще машины управляемые потоками данных. Там тоже такая же схема..

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

Посмотрел Node. Не то совсем.. игрушка.. Я повторюсь что такое события у меня.

События определяются объектами класса Event. Класс Event имеет свойства Condition, Connection, Fire и Event. Свойство Condition это выражение, при истинности которого событие считается происшедшим и запускается процедура обработки события, если она определена (значние свойства Event). Отсутствие значения в свойстве Condition означает безусловное событие. Проверка свойства Condition происходит при выполнении событий определенных свойством Connection, которое связывает данное событие со списком внешних событий (подписаться на событие). Таким образом, свойство Connection представляет собой группу ссылок на события, к которым подписывается создаваемое событие. Так как свойство Connection представляет собой группу событий, то запуск проверки свойства Condition может происходить от срабатывания одного события из группы или от срабатывания всех событий группы. Группа событий в свойстве Connection называется комплектом. И соответственно комплекты бывают вида И/Или. Эти два вида комплектов отличаются методом объединения в группы. Режим Или определяется группой в квадратных скобках с вертикальной чертой. Остальные варианты группировки определяют режим И.
Свойство Event содержит группу операторов для выполнения, если процедура обработки события определена в самом событии или ссылку на процедуру или блок обработки события. По этой причине процедура обработки события самостоятельное понятие и не является обязательно процедурой. Это может быть и блок, перехватывающий события. Таким методом происходит перехват и обработка ошибок, которые тоже события.

Вчитайся внимательно если интересует

M>>Ну так и делается

Никто не требует, чтобы все было внутри цикла

И никто не собирается писать цикл длинной 10 000 строчек.

M>>Когда занимаешься отладкой программы, можно не уследить за логикой или нечаянно удалить это событие. Могут возникнуть проблемы. Оформив это циклом, мы четко и явно прописываем, что именно мы делаем

B>Видимо у меня не получается объяснить. Можешь представить что тебе нужно написать программу моделирующую деятельность предприятия или управление государством? Вот если кто-то уволится, то кем, за что..по каким законам и приказам. Какие действия после увольнения. Кто уполномочен и какие процедуры при найме нового человека.. И так по всей деятельности предпрития. Задолбаешься в лоб писать. А потом могут поменяться инструкции и за ним появится новая схема управления. А если разбить на события, то писать прогу, и апгретить будет значительно легче. События сами позацепляются за что нужно, да еще и можно протестить на полноту и прочую дребдень.

Ничего мире не происходит автоматически. Аналогично и события никуда автоматически не привяжутся. Их привяжет программист. Забудет привязать — огребет все те же проблемы.

B>Посмотрел Node. Не то совсем.. игрушка.. Я повторюсь что такое события у меня.

B>События определяются объектами класса Event. Класс Event имеет свойства Condition, Connection, Fire и Event. Свойство Condition это выражение, при истинности которого событие считается происшедшим и запускается процедура обработки события, если она определена (значние свойства Event). Отсутствие значения в свойстве Condition означает безусловное событие. Проверка свойства Condition происходит при выполнении событий определенных свойством Connection, которое связывает данное событие со списком внешних событий (подписаться на событие). Таким образом, свойство Connection представляет собой группу ссылок на события, к которым подписывается создаваемое событие. Так как свойство Connection представляет собой группу событий, то запуск проверки свойства Condition может происходить от срабатывания одного события из группы или от срабатывания всех событий группы. Группа событий в свойстве Connection называется комплектом. И соответственно комплекты бывают вида И/Или. Эти два вида комплектов отличаются методом объединения в группы. Режим Или определяется группой в квадратных скобках с вертикальной чертой. Остальные варианты группировки определяют режим И.
B>Свойство Event содержит группу операторов для выполнения, если процедура обработки события определена в самом событии или ссылку на процедуру или блок обработки события. По этой причине процедура обработки события самостоятельное понятие и не является обязательно процедурой. Это может быть и блок, перехватывающий события. Таким методом происходит перехват и обработка ошибок, которые тоже события.

B>Вчитайся внимательно если интересует

Описанная схема напоминает механимз слоты/сигналы, что есть в Qt, но с дополнительными плюшками и сахаром. Согласен, похожая схема была бы интересна, как дополнение к существующим инструментам.

T>>На самом деле, про события это одна из немногих вменяемых идей в его языке, просто он её (и ни одну другую) объяснить по русски не может.

M>>>Не говоря уже о том, что длина входящих данных нам может быть заранее неизвестна.

T>>Тогда он повесил бы обработчик на read() == -1.

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

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

И вообще, если машина простая, может стоит начать ее реализовывать?

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

M>>>Ну так и делается

Никто не требует, чтобы все было внутри цикла

И никто не собирается писать цикл длинной 10 000 строчек.

M>>>Когда занимаешься отладкой программы, можно не уследить за логикой или нечаянно удалить это событие. Могут возникнуть проблемы. Оформив это циклом, мы четко и явно прописываем, что именно мы делаем

B>>Видимо у меня не получается объяснить. Можешь представить что тебе нужно написать программу моделирующую деятельность предприятия или управление государством? Вот если кто-то уволится, то кем, за что..по каким законам и приказам. Какие действия после увольнения. Кто уполномочен и какие процедуры при найме нового человека.. И так по всей деятельности предпрития. Задолбаешься в лоб писать. А потом могут поменяться инструкции и за ним появится новая схема управления. А если разбить на события, то писать прогу, и апгретить будет значительно легче. События сами позацепляются за что нужно, да еще и можно протестить на полноту и прочую дребдень.

M>Ничего мире не происходит автоматически. Аналогично и события никуда автоматически не привяжутся. Их привяжет программист. Забудет привязать — огребет все те же проблемы.
Я думаю прочитав подробнее ты поймешь механизм. С одной стороны подписки на инициирующие события. Затем условие запускающее событие и процедура обработки. Связь эта более динамична и не требует привязки где-то в самом тексте программы. Однако позволяет осуществить проверку наличия связей и процедур обработки, и отсутствие "висящих" событий.

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

M>Описанная схема напоминает механимз слоты/сигналы, что есть в Qt, но с дополнительными плюшками и сахаром. Согласен, похожая схема была бы интересна, как дополнение к существующим инструментам.
Спасибо! Сегодня какой-то удачный день. За пол года сегодня ты второй кто эту фишку понял. До этого было сплошное фи. Если так и дальше пойдет, то еще через полгода появятся въехавшие в гуппирование и в реализацию. Это уже будет перелом. Пока въехавших нет. Если интересует то почитай как группы выполняются.. Ну и т.д.. С именованием и текстом думаю можно и позже разобраться. Это уже фигня. Но, я вынужден был в документе поставить именование раньше группирования. Иначе было бы не логично.

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

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

И вообще, если машина простая, может стоит начать ее реализовывать?

Я то считаю что могу объяснить. Для этого надо просто заинтересованые слушатели. А я и реализовываю потихоньку. Одному трудно. Хотя бы 4 человека было. И для критики и для работы. Оппонировать самому себе тяжело. Можно глупостей наделать. Да и может кто чего подскажет. А план есть. И как делать и что и для чего..

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

И вообще, если машина простая, может стоит начать ее реализовывать?

B>Я то считаю что могу объяснить.

Вы невероятно заблуждаетесь.

Ну, или можете, но не используете этих возможностей в документах описания языка и на данном форуме.

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

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

И вообще, если машина простая, может стоит начать ее реализовывать?

B>>Я то считаю что могу объяснить.

T>Вы невероятно заблуждаетесь.

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

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

И вообще, если машина простая, может стоит начать ее реализовывать?

B>>>Я то считаю что могу объяснить.

T>>Вы невероятно заблуждаетесь.

T>>Ну, или можете, но не используете этих возможностей в документах описания языка и на данном форуме.
B>Что именно не понятно из прочитанного? Задайте вопрос. Отвечу. Исправлю. Для того и выложил что б обсудить.

Я вам написал что не так ещё в марте. http://www.rsdn.ru/forum/philosophy/3944143.aspx
Прошло уже почти 4 месяца. Вы ничего не ответили и ничего не исправили.

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

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

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

И вообще, если машина простая, может стоит начать ее реализовывать?

B>>>>Я то считаю что могу объяснить.

T>>>Вы невероятно заблуждаетесь.

T>>>Ну, или можете, но не используете этих возможностей в документах описания языка и на данном форуме.
B>>Что именно не понятно из прочитанного? Задайте вопрос. Отвечу. Исправлю. Для того и выложил что б обсудить.

T>Я вам написал что не так ещё в марте. http://www.rsdn.ru/forum/philosophy/3944143.aspx
T>Прошло уже почти 4 месяца. Вы ничего не ответили и ничего не исправили.

T>Выложили чтобы обсудить — вы это получили, вне всяких сомнений. Только всё обсуждение проходит на всё том же никому непонятном языке, а документация к проекту не меняется.
За отсутствие новой версии документа виноват конечно. Я переписываю демку. В ходе общения здесь и в ходе собственно программирования возникли новые мысли. Это еще раз повлияло на синтакис. Потому примеры и кое что еще прийдется заново переписывать. Я решил как задышит транслятор, так уже и займусь вылизыванием документа. Будет издевательством предлагать новую версию зная что она уже старая. Например, было две разных операции присвоения. Я придумал как можно обойтись одной. Хотя суть их по прежнему будет разной. А знак теперь будет один. И т.п.
А насчет того что вы предложили на двух страницах введение сделать так я сделал. Если пропустить правила описания грамматики которые применяются у меня (ну, а где ж их еще писать если не в начале?) как раз за ними и идут основные концепции.

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

B>Спасибо. Я действительно плохо объясняю. Внутри себя в голове есть и там все понятно..

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

T>Примерно так же, как использование декларативных сканнеров, например lex, лучше чем

Если тебе хочется декларации, то есть, к примеру, Rx.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

T>>Примерно так же, как использование декларативных сканнеров, например lex, лучше чем

AVK>Если тебе хочется декларации, то есть, к примеру, Rx.

Это что, надо поправить фразу что-ли? Хорошо.

"Примерно так же, как использование декларативных сканнеров, например lex или Rx, лучше чем"...

остальной смысл сообщения не изменился.

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

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

B>>Спасибо. Я действительно плохо объясняю. Внутри себя в голове есть и там все понятно..

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

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

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

M>>>>Ну так и делается

Никто не требует, чтобы все было внутри цикла

И никто не собирается писать цикл длинной 10 000 строчек.

M>>>>Когда занимаешься отладкой программы, можно не уследить за логикой или нечаянно удалить это событие. Могут возникнуть проблемы. Оформив это циклом, мы четко и явно прописываем, что именно мы делаем

B>>>Видимо у меня не получается объяснить. Можешь представить что тебе нужно написать программу моделирующую деятельность предприятия или управление государством? Вот если кто-то уволится, то кем, за что..по каким законам и приказам. Какие действия после увольнения. Кто уполномочен и какие процедуры при найме нового человека.. И так по всей деятельности предпрития. Задолбаешься в лоб писать. А потом могут поменяться инструкции и за ним появится новая схема управления. А если разбить на события, то писать прогу, и апгретить будет значительно легче. События сами позацепляются за что нужно, да еще и можно протестить на полноту и прочую дребдень.

M>>Ничего мире не происходит автоматически. Аналогично и события никуда автоматически не привяжутся. Их привяжет программист. Забудет привязать — огребет все те же проблемы.
B>Я думаю прочитав подробнее ты поймешь механизм. С одной стороны подписки на инициирующие события. Затем условие запускающее событие и процедура обработки. Связь эта более динамична и не требует привязки где-то в самом тексте программы. Однако позволяет осуществить проверку наличия связей и процедур обработки, и отсутствие "висящих" событий.

Как это она не требует привязки??? Берем пример:

Dim Integer Len:                                              ' Длина текста
Dim Integer Ind                                                ' Индекс проверяемого символа
Exp Boolean EndE=(Len=Ind):                        ' Логическое выражение
New Event EndText                                         ' Формирование события
 {Condition=:EndE
   Connection.Add [|Ind.Chang, Len.Change]
      Event: =MsgBox(“Конец текста”)
 }

Событие EndText само появилось? Условие EndE само появилось? Связка Connection.Add сама появилась?

M>>Описанная схема напоминает механимз слоты/сигналы, что есть в Qt, но с дополнительными плюшками и сахаром. Согласен, похожая схема была бы интересна, как дополнение к существующим инструментам.
B>Спасибо! Сегодня какой-то удачный день. За пол года сегодня ты второй кто эту фишку понял. До этого было сплошное фи. Если так и дальше пойдет, то еще через полгода появятся въехавшие в гуппирование и в реализацию. Это уже будет перелом. Пока въехавших нет.

Ну если ты не можешь внятно объяснить, что это такое, то

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

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

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

И вообще, если машина простая, может стоит начать ее реализовывать?

B>Я то считаю что могу объяснить. Для этого надо просто заинтересованые слушатели.

Здесь все заинтересованные. Но за 100 сообщений флейма появился только один вменяемый пример. И то со второй-третьей попытки

B>А я и реализовываю потихоньку. Одному трудно. Хотя бы 4 человека было. И для критики и для работы. Оппонировать самому себе тяжело. Можно глупостей наделать. Да и может кто чего подскажет. А план есть. И как делать и что и для чего..

Для этого и нужно:
1. Выложить код на сайт типа GitHub, вместе с планом, описанием и т.п. Чтобы заинтересованные люди не искали, где сейчас последняя версия, а могли в любой момент ее централизованно скачать. А то и поучаствовать
2. Не разводить воду и делать пассы руками, а выложить хотя бы пять примеров по схеме:

1. Задача
2. Решение этой задачи на Lada
3. Чем это решение лучше, чем уже существующие

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

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

T>"Примерно так же, как использование декларативных сканнеров, например lex или Rx, лучше чем"...

Rx это не декларативный сканер.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

T>>"Примерно так же, как использование декларативных сканнеров, например lex или Rx, лучше чем"...

AVK>Rx это не декларативный сканер.

То есть он не совсем к месту был упомянут?

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

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

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

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

И вообще, если машина простая, может стоит начать ее реализовывать?

B>>Я то считаю что могу объяснить. Для этого надо просто заинтересованые слушатели.

M>Здесь все заинтересованные. Но за 100 сообщений флейма появился только один вменяемый пример. И то со второй-третьей попытки

Извини, в документе куча примеров. Вот могу здесь варианты сортировки скинуть. Версия синтаксиса может и старая, но если где не тот знак это не принципиально.

Sub Sort (A[]: Integer)
{
  Dim  Integer ( I,   J,  Count=Int(A.Lenght/2)-1,  NewCount )           ' Определение переменных
  Exp  Integer {  Next= J+1  Last= A.Lenght-J-1   Prev= A.Lenght-J-2}    ' Определение блоков  
  Block   {
       ChangUp      { If A[J]<A[Next] A[J] ОБМЕН A[Next]} 
       ChangDown { If A[Prev]<A[Last]  A[Prev] >< A[Last] }               ' Операция >< обмен значениями
              }
  If A.Lenght<2  Exit Sub Sort               ' Если есть что сортировать
  For I=0 To Count
    {
        NewCount:= A.Lenght-I-1
        For J=I To NewCount {ChangUp ChangDown}
    }
} ' Конец процедуры

Вот пример вычисления NOD с помощью автоматов. Используя механизм событий. Сначала создаем класс автоматов NOD


Automation Nod ((I, J): Integer)
{
    Starter (More, Less)
    New  Event More{Condition=:I<J Connection.Add (| I.Chang, J.Change) Sub{J:=J-I}
    New  Event Less  {Condition=:I<J Connection.Add (| I.Chang, J.Change ) Sub{I:=I-J}
    Public Event Eq {Condition=:I=J Connection.Add (| I.Chang, J.Change ) Sub{Nod.Off}
}

Выполнение оператора Off влечет за собой одноименное событие. Автомат может выключить себя сам, а возможно это сделать и вне автомата методом Off. Такая схема позволяет запустить на выполнение несколько автоматов и синхронизировать их выполнение событиями. Данный автомат останавливается самостоятельно после вычисления. Кроме того внешнее событие Eq может послужить для информирования о готовности вычисления.

Синхронизация с событием Eq, и выключение автомата Nod.

Dim Integer (A=5, B=35)
New Nod AV (A, B)                         'Создание автомата Nod
AV.OnStart                                'Включение одновременно со стартером.
Event {Connection=:AV.Eq}                 'Оператор синхронизации. Здесь выполнение программы остановится ожидая события AV.Eq
Nod.Stop                                  'Выключение автомата Nod

И пример логического разбора. Интерпретации. Определим следующие предикаты.

Predicate 
  {
     Positive (X: Integer) {Positive=X>0} ' Предикат  Positive
     Четное (X: Integer) {Здесь проверка на четность. Знак операции И не проходит}
  }

Теперь определим множество, на котором будет выполняться интерпретация. В нашем случае это множества целых чисел и объекты-значения I и Y.
Dim Integer (I=-50000, Y=108)
Высказывание со знаком вопроса называется целевым высказыванием. Этот знак запускает не императивное вычисление, а осуществляет попытку логического разбора. Определим целевое высказывание.
If Positive (I ^ Y)?
Сейчас мы покажем как можно решить эту задачу без возведения в 108 степень. Для этого определим следующие высказывания на множестве Integer и Positiv.

Utterance
{
    ForAll (А: Integer, B: Positive) ‹Positive (A)  Positive (A^B) ›
    ForAll (А: Integer, B: Positive)‹Четное (B)  Positive (A^B) ›
}

Знак "следует" здесь не прошел. На его месте квадратик. Замечу, что в качестве параметров могут быть не только объекты классов или типов, но и объекты принадлежащие множеству или принадлежащие множеству определенному предикатом, как в нашем примере(Positive).
Интерпретация выполняется так.
На первом шаге резолюции ищутся высказывания относительно заданного целевого высказывания Positive (I ^ Y) на множестве функций "^", и находящееся в правой части после знака "следует" на предмет нельзя ли его упростить. Оказывается, у нас есть такое высказывание есть и не одно. Выбираем первое. Проверяем область действия (А: Integer: B: Positiv) и нас она нас устраивает. И, стало быть, мы можем смело полагаться на исследование высказывания в левой части от знака "следует". Это предикат Positive (A). Данный предикат уже упростить не возможно. Он вычисляется, (вместо А подставляем значение -5000) и дает отрицательный результат. При положительном результате вопрос был бы закрыт, но не все потеряно, у нас есть еще не проанализированное высказывание и область действия нас устраивает. Возвращаемся к нему. Проверяем предикат Четное (X: Integer) на истинность, подставляя в качестве параметра значение 108, и получаем положительный результат. Целевое высказывание определено без вычислений.

M>Для этого и нужно:
M>1. Выложить код на сайт типа GitHub, вместе с планом, описанием и т.п. Чтобы заинтересованные люди не искали, где сейчас последняя версия, а могли в любой момент ее централизованно скачать. А то и поучаствовать
M>2. Не разводить воду и делать пассы руками, а выложить хотя бы пять примеров по схеме:
M>

M>1. Задача
M>2. Решение этой задачи на Lada
M>3. Чем это решение лучше, чем уже существующие

Сори, я не знаю что это за сайт... Расскажи..Попробую.. Но вот чем решения на lade лучше это большй вопрос. В принципе все это где-то и в каком то виде есть в разных языках. Я предлагаю инструмент в котором есть выбор. Это не все любопытные примеры..Но так навскидку. Еще много интересного есть. Я принялся написать документ для быстрого входа чисто на примерах. Но, не так быстро дело идет. Думаю месяц у меняяя уйдет на это.

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

Еще раз сори. Я работаю один. Мне еще на хлеб надо зарабатывать. А работы много. Не успеваю. Хотя чуствую что дело идет к завершению.

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

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

Благодарю за участие.

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

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

B>Посмотрел Node. Не то совсем.. игрушка.. Я повторюсь что такое события у меня.

B>События определяются объектами класса Event. Класс Event имеет свойства Condition, Connection, Fire и Event. Свойство Condition это выражение, при истинности которого событие считается происшедшим и запускается процедура обработки события, если она определена (значние свойства Event). Отсутствие значения в свойстве Condition означает безусловное событие. Проверка свойства Condition происходит при выполнении событий определенных свойством Connection, которое связывает данное событие со списком внешних событий (подписаться на событие). Таким образом, свойство Connection представляет собой группу ссылок на события, к которым подписывается создаваемое событие. Так как свойство Connection представляет собой группу событий, то запуск проверки свойства Condition может происходить от срабатывания одного события из группы или от срабатывания всех событий группы. Группа событий в свойстве Connection называется комплектом. И соответственно комплекты бывают вида И/Или. Эти два вида комплектов отличаются методом объединения в группы. Режим Или определяется группой в квадратных скобках с вертикальной чертой. Остальные варианты группировки определяют режим И.
B>Свойство Event содержит группу операторов для выполнения, если процедура обработки события определена в самом событии или ссылку на процедуру или блок обработки события. По этой причине процедура обработки события самостоятельное понятие и не является обязательно процедурой. Это может быть и блок, перехватывающий события. Таким методом происходит перехват и обработка ошибок, которые тоже события.

Ок. Это понятно. В принципе, звучит толково.

Ждем дальше, глядишь, по чуть-чуть разберем остальные аспекты языка.

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

T>То есть он не совсем к месту был упомянут?

К месту. Просто это куда более универсальный инструмент.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

E__>Ок. Это понятно. В принципе, звучит толково.

E__>Ждем дальше, глядишь, по чуть-чуть разберем остальные аспекты языка.
Спасибо. Смотрю так в диалоге лучше получается чем документ вывалить. Тогда я позволю о группах объяснится. Это принципиальная часть и касается работы виртуальной машины. К сожалению подстрочные и надстрочные знаки я не могу здесь проставить, но надеюсь будет понятно. Хотя лажа, конечно.

Обычно (и привычно) группирование объектов осуществляется скобками. Собственно для этого их и придумали. В системе используются круглые («)» и «(»), квадратные («[» и «]»),), фигурные («{» и «}»),), текстовые (««» и «»»),) и именные («"») скобки.
С назначением текстовых и именных скобок мы уже познакомились.
В системе Lada существует два вида применения скобок для группирования объектов и для предопределения групп. Группирование объектов это то, что мы делаем, объединяя скобками буквы, лексемы, операторы и вообще все объекты. Если скобки пустые (т.е. нет объектов в скобках) то это предопределение группы. Предопределение заключается в определении метода группирования объектов, которых еще нет, но есть необходимость объединить будущие объекты в группу с какими-то общими свойствами по методу доступа, обращения, способов добавления или удаления, фактически определяя класс (или метод) объединения будущих объектов. Или как мы будем называть, определяя организацию группы (Organization).

Группирование объектов. Правила выполнения групп.

Группирование объектов допускается двумя способами с последовательным выполнением группы и произвольным выполнением группы (классы Tape и Group). Поступая в виртуальную машину, каждый объект выполняется. Поступление объектов группы в виртуальную машину выполняется либо последовательно (класс Tape), либо в произвольном порядке (класс Group). Результат выполнения оператора или объекта в виртуальной машине завершается присвоением логического значения обязательному свойству для всех объектов Result. Если в результате исполнения в теговой машине объекта или оператора получим Result =True, то будем называть такое выполнение успешным выполнением объекта, или там где понятно, что речь идет об успешном выполнении просто выполнение. Если Result = False будем считать объект не выполненным или выполненным не успешно. Успешное выполнение группы зависит от успешного выполнения объектов содержащихся в группе (успешное выполнение содержимого группы), способа объединения в группу и свойств группы. Группы имеют свойства Min, Max и Extract.
Свойство Extract определяет количество успешно выполненных объектов в группе для того, что бы выполнение содержимого группы считалось успешным. По умолчанию значение свойства Extract=0, что означает обязательное успешное выполнение всех объектов группы. Значение свойства Extract по умолчанию можно изменить на часто применяемое Extract=1 знаком «.» сразу за открывающей скобкой, что означает успешное выполнение группы, если успешно выполнился точно один объект из группы. Любое значение свойства Extract можно определить значением после знака «.» следующего непосредственно без пробела за открывающейся скобкой.
Свойства Min и Max определяются соответственно подстрочным и надстрочным значением после закрывающей скобки и определяют минимальное и максимальное значение успешных выполнений содержимого группы для успешного выполнения группы. При успешном выполнении содержимого группы, если количество успешных выполнений меньше значения свойства Max выполнение группы продолжается. В противном случае выполнение группы прекращается.
Если после прекращение выполнения группы количество успешных выполнений больше или равно значению свойства Min, то выполнение группы считается успешным. В противном случае не успешным.
Значение свойства Min=0 допускает ни одного успешного выполнения группы. Значения свойств по умолчанию следующее Min=1, Max=1. Диапазон значений свойств Min и Max от 0 до 255 .
Значения свойств Min и Max можно определить не только подстрочным и надстрочным значением после закрывающей скобки, но и через точку после определения свойства Extract.

Группирование с последовательным выполнением. Класс Tape.

Группирование с последовательным выполнением определяется круглыми или фигурными скобками (объекты класса Tape) и допускает только последовательное выполнение объектов. При использовании группирования объектов круглыми скобками их необходимо разделять запятыми. Объекты, сгруппированные фигурными скобками нет необходимости разделять запятыми. Выбор применяемых скобок за программистом.

Пример 1. Присвоение свойствам группы Word значений Min=2 и Max=40

Word {Letter}2 40

Данная группа выполняется максимум 40 раз, но для ее успешного выполнения достаточно одного успешного выполнения группы.

Пример 2. Группирование операторов для многократного выполнения.

{
I:=J+ R-1
}225

Данная группа выполняется 25 раз, хотя для успешного ее выполнения достаточно выполниться 2 раза.

Группирование с произвольным выполнением. Класс Group

Группирование с произвольным выполнением (Group) определяется квадратными скобками и допускает обращение к любому объекту в группе, обеспечивая прямой доступ, и позволяет выполнять каждый оператор (объект) независимо и одновременно (если это возможно), т.е. осуществлять параллельную обработку.

Пример 3. Группирование с произвольным доступом квадратными скобками.

If
[
X >0 {…}
X =0 {…}
X <0 {…}
]

В этом примере выполнение проверки трех условий может осуществляться одновременно.

Пример 4. Определение модификатора.

Determination Модификатор [. «Private» «Public» «Protected»]
Таким образом, мы определили модификатор как один из трех объектов «Private», «Protected» или «Public» содержащихся в квадратных скобках. Наличие прямого доступа здесь не принципиально.

Пример 5. Определение класса Group.

Public Class Group
{ Public Dim Integer Min=1
Public Dim Integer Max=1
Public Dim Integer Extract=0
}

Пример 6. Определение класса Group. Короткий вариант.

Public Class Group Public Dim Integer (Min=1, Max=1, Extract=0)

T>>То есть он не совсем к месту был упомянут?

AVK>К месту. Просто это куда более универсальный инструмент.

Отлично, тогда будет формулировка "Примерно так же, как использование декларативных сканнеров, например lex или куда-более-универсального-инструмента-Rx, лучше чем...". Надеюсь, вы теперь удовлетворены.

Но, на всякий случай, уточню: не было задачи, никто не искал инструмент. lex был упомянут для примера, чтобы показать что такой подход (а не lex или Rx или любой другой софт) лучше, чем миллионы if-ов.

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

И вообще, если машина простая, может стоит начать ее реализовывать?

B>>>Я то считаю что могу объяснить. Для этого надо просто заинтересованые слушатели.

M>>Здесь все заинтересованные. Но за 100 сообщений флейма появился только один вменяемый пример. И то со второй-третьей попытки

B>Извини, в документе куча примеров.

Подавляющее большинство из которых выглядит так:

Пример 1.3. Именование объекта типа Integer присвоением значения Ширина свойству Name.

10 ‘ Name=: «Ширина» ’

операторы у меня тоже объекты и могут иметь имена и оператор, например Exit указывает имя объекта-оператора (а может и класса) из которого необходимо выйти. Получается например такая картина.
For i=0 to n
...
Exit I

То в операторе Exit I-это имя оператора For, а не имя переменной.

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

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

B>

B>Sub Sort (A[]: Integer)
B>{
B>  Dim  Integer ( I,   J,  Count=Int(A.Lenght/2)-1,  NewCount )           ' Определение переменных
B>  Exp  Integer {  Next= J+1  Last= A.Lenght-J-1   Prev= A.Lenght-J-2}    ' Определение блоков  
B>  Block   {
B>       ChangUp      { If A[J]<A[Next] A[J] ОБМЕН A[Next]} 
B>       ChangDown { If A[Prev]<A[Last]  A[Prev] >< A[Last] }               ' Операция >< обмен значениями
B>              }
B>  If A.Lenght<2  Exit Sub Sort               ' Если есть что сортировать
B>  For I=0 To Count
B>    {
B>        NewCount:= A.Lenght-I-1
B>        For J=I To NewCount {ChangUp ChangDown}
B>    }
B>} ' Конец процедуры

B>

Переусложнение и загромождение на ровном месте. имхо.

B>Вот пример вычисления NOD с помощью автоматов. Используя механизм событий. Сначала создаем класс автоматов NOD

Что такое NOD?

B>


B>Automation Nod ((I, J): Integer)
B>{
B>    Starter (More, Less)
B>    New  Event More{Condition=:I<J Connection.Add (| I.Chang, J.Change) Sub{J:=J-I}
B>    New  Event Less  {Condition=:I<J Connection.Add (| I.Chang, J.Change ) Sub{I:=I-J}
B>    Public Event Eq {Condition=:I=J Connection.Add (| I.Chang, J.Change ) Sub{Nod.Off}
B>}
B>

B>Выполнение оператора Off влечет за собой одноименное событие. Автомат может выключить себя сам, а возможно это сделать и вне автомата методом Off. Такая схема позволяет запустить на выполнение несколько автоматов и синхронизировать их выполнение событиями.

Хотелось бы увидеть это на примере.

B>Данный автомат останавливается самостоятельно после вычисления. Кроме того внешнее событие Eq может послужить для информирования о готовности вычисления.

B>Синхронизация с событием Eq, и выключение автомата Nod.
B>

B>Dim Integer (A=5, B=35)
B>New Nod AV (A, B)                         'Создание автомата Nod
B>AV.OnStart                                'Включение одновременно со стартером.
B>Event {Connection=:AV.Eq}                 'Оператор синхронизации. Здесь выполнение программы остановится ожидая события AV.Eq
B>Nod.Stop                                  'Выключение автомата Nod
B>

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

B>И пример логического разбора. Интерпретации. Определим следующие предикаты.

B>

B>Predicate 
B>  {
B>     Positive (X: Integer) {Positive=X>0} ' Предикат  Positive
B>     Четное (X: Integer) {Здесь проверка на четность. Знак операции И не проходит}
B>  }
B>

B>Теперь определим множество, на котором будет выполняться интерпретация. В нашем случае это множества целых чисел и объекты-значения I и Y.
B>Dim Integer (I=-50000, Y=108)
B>Высказывание со знаком вопроса называется целевым высказыванием. Этот знак запускает не императивное вычисление, а осуществляет попытку логического разбора. Определим целевое высказывание.
B>If Positive (I ^ Y)?
B>Сейчас мы покажем как можно решить эту задачу без возведения в 108 степень. Для этого определим следующие высказывания на множестве Integer и Positiv.
B>

B>Utterance
B>{
B>    ForAll (А: Integer, B: Positive) ‹Positive (A)  Positive (A^B) ›
B>    ForAll (А: Integer, B: Positive)‹Четное (B)  Positive (A^B) ›
B>}
B>

B>Знак "следует" здесь не прошел. На его месте квадратик.

Естественно. Именно поэтому весь цивилизованный мир не использует странные символы в программах. Печальный опыт APL был не зря.

B>Замечу, что в качестве параметров могут быть не только объекты классов или типов, но и объекты принадлежащие множеству или принадлежащие множеству определенному предикатом, как в нашем примере(Positive).

Это называется, в частности, duck typing (утиная типизация).

B>Интерпретация выполняется так.
B>На первом шаге резолюции ищутся высказывания относительно заданного целевого высказывания Positive (I ^ Y) на множестве функций "^", и находящееся в правой части после знака "следует" на предмет нельзя ли его упростить. Оказывается, у нас есть такое высказывание есть и не одно. Выбираем первое. Проверяем область действия (А: Integer: B: Positiv) и нас она нас устраивает. И, стало быть, мы можем смело полагаться на исследование высказывания в левой части от знака "следует". Это предикат Positive (A). Данный предикат уже упростить не возможно. Он вычисляется, (вместо А подставляем значение -5000) и дает отрицательный результат. При положительном результате вопрос был бы закрыт, но не все потеряно, у нас есть еще не проанализированное высказывание и область действия нас устраивает. Возвращаемся к нему. Проверяем предикат Четное (X: Integer) на истинность, подставляя в качестве параметра значение 108, и получаем положительный результат. Целевое высказывание определено без вычислений.

Ну, это понятно. Prolog в качестве DSL'я для языка.

M>>Для этого и нужно:
M>>1. Выложить код на сайт типа GitHub, вместе с планом, описанием и т.п. Чтобы заинтересованные люди не искали, где сейчас последняя версия, а могли в любой момент ее централизованно скачать. А то и поучаствовать
M>>2. Не разводить воду и делать пассы руками, а выложить хотя бы пять примеров по схеме:
M>>

M>>1. Задача
M>>2. Решение этой задачи на Lada
M>>3. Чем это решение лучше, чем уже существующие

B>Сори, я не знаю что это за сайт... Расскажи..Попробую..

Тьфу, елки

Даже ссылки приводил. Кратко: публичный онлайн репозиторий кода. Надеюсь, не надо объяснять, что такое репозиторий и контроль версий?

GitHub: git
Google Code: subversion/mercurial
Bitbucket: mercurial
Sourceforge: CVS/subversion/git
и т.п.

B>Но вот чем решения на lade лучше это большй вопрос. В принципе все это где-то и в каком то виде есть в разных языках. Я предлагаю инструмент в котором есть выбор.

Просто выбор никого не интересует. Более тго, для этого есть Лисп

Людей интересует именно «лучшесть». Насколько более эффективно новый язык позволит решать те или иные задачи.

B>Это не все любопытные примеры..Но так навскидку. Еще много интересного есть. Я принялся написать документ для быстрого входа чисто на примерах. Но, не так быстро дело идет. Думаю месяц у меняяя уйдет на это.

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

B>Еще раз сори. Я работаю один. Мне еще на хлеб надо зарабатывать. А работы много. Не успеваю. Хотя чуствую что дело идет к завершению.

Для того, чтобы один раз выложить наработки на тот же GitHub требуется 2 минуты дествий (и еще 5, чтобы собственно установить git). Аналогично для любого другого онлайн-репозитория. Это если говорить про пункт 1 выше.

E__>>Ок. Это понятно. В принципе, звучит толково.

E__>>Ждем дальше, глядишь, по чуть-чуть разберем остальные аспекты языка.
B>Спасибо. Смотрю так в диалоге лучше получается чем документ вывалить. Тогда я позволю о группах объяснится. Это принципиальная часть и касается работы виртуальной машины. К сожалению подстрочные и надстрочные знаки я не могу здесь проставить, но надеюсь будет понятно. Хотя лажа, конечно.

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

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

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

E__>>Ок. Это понятно. В принципе, звучит толково.

E__>>Ждем дальше, глядишь, по чуть-чуть разберем остальные аспекты языка.
B>Спасибо. Смотрю так в диалоге лучше получается чем документ вывалить. Тогда я позволю о группах объяснится. Это принципиальная часть и касается работы виртуальной машины. К сожалению подстрочные и надстрочные знаки я не могу здесь проставить, но надеюсь будет понятно. Хотя лажа, конечно.

Вторая лажа — придумывание собственных терминов.

B>Группирование объектов допускается двумя способами с последовательным выполнением группы и произвольным выполнением группы (классы Tape и Group).

Если и то и другое группа, почему только одна называется группой? Почему не Sequence(SeqGroup) и Random(RndGroup)? Зачем нуны пляски с приседанием в виде толпы разных скобок? Которые еще и близки визуально.

B> Группирование с последовательным выполнением. Класс Tape.
B>Пример 1. Присвоение свойствам группы Word значений Min=2 и Max=40
B>Word {Letter}2 40

Или

Word Sequence(Letter)[2,40]

B>Данная группа выполняется максимум 40 раз, но для ее успешного выполнения достаточно одного успешного выполнения группы.
B>Пример 2. Группирование операторов для многократного выполнения.

B>{
B> I:=J+ R-1
B>}225

Или

Sequence(I:=J + R-1)[2,25]

Ну и т.п.

Ах, да:

Determination Модификатор [. «Private» «Public» «Protected»]

determination

1) решительность; решимость
2) решение, разрешение (спора)
3) юр. определение, постановление (суда)
4) определение; установление, задание, фиксирование
5) книжн. стремление, тенденция (к чему-л.) ; пристрастие (к чему-л.)
6) мед. прилив (крови)

При том, что весь мир использует для понятия «определение» слово "define"

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

M> операторы у меня тоже объекты и могут иметь имена и оператор, например Exit указывает имя объекта-оператора (а может и класса) из которого необходимо выйти. Получается например такая картина.
M>For i=0 to n
M>...
M>Exit I

M>То в операторе Exit I-это имя оператора For, а не имя переменной.
M>[/q]

M>Что это за примеры? ЧТо это все значит? Какая практическая в них необходимость? Как их применять? На эти вопросы нет ни единого ответа.
Пока нет ответа. Сейчас попробую дать. Вот оператор For это объект класса For с именем и т.д.. Это мы пишем программу. Она же является документом. Т.е. это частный случай документа, который мы можем наполнить и формами, и вообще объектами любого классса. Т.е. ниже приведенный код

Form Первый
  { Me.Size=20;80
    TextBox {}
    Button { Me.Text="Start" ...}
  }

Это просто форма с текстбоксом и кнопкой..
Если мы применяем к этой форме оператор New, то эта форма создастся (и разместиться в памяти) динамически во время выполнения.

New Form Первый
  { Me.Size=20;80
    TextBox {}
    Button { Me.Text="Start" ...}
  }

Вот в таком виде мы обычно и используем объекты в программе.
Так вот зачем так много слов про этот Exit и про имя, а дело в том, что адрес объекта к которому необходимо обратиться находится в теле документа, а не формируется через заголовок процедуры (в силу динамического размещения), так как происходит в случае обращения к объектам созданым опреторами Dim и New. Просто я напоминаю что это не только язык программирвания, но и язык документирования. Для анализа объектов в теле документа адресация осуществляется так называемым указателем и там немного другой принцип. Вот оператор Exit это частный случай такого указателя (Pointer).

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

B>>

B>>Sub Sort (A[]: Integer)
B>>{
B>>  Dim  Integer ( I,   J,  Count=Int(A.Lenght/2)-1,  NewCount )           ' Определение переменных
B>>  Exp  Integer {  Next= J+1  Last= A.Lenght-J-1   Prev= A.Lenght-J-2}    ' Определение блоков  
B>>  Block   {
B>>       ChangUp      { If A[J]<A[Next] A[J] >< A[Next]} 
B>>       ChangDown { If A[Prev]<A[Last]  A[Prev] >< A[Last] }               ' Операция >< обмен значениями
B>>              }
B>>  If A.Lenght<2  Exit Sub Sort               ' Если есть что сортировать
B>>  For I=0 To Count
B>>    {
B>>        NewCount:= A.Lenght-I-1
B>>        For J=I To NewCount {ChangUp ChangDown}
B>>    }
B>>} ' Конец процедуры

B>>

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

B>>Вот пример вычисления NOD с помощью автоматов. Используя механизм событий. Сначала создаем класс автоматов NOD

M>Что такое NOD?
НОД по русски.. Школа.. арифметика.

B>>


B>>Automation Nod ((I, J): Integer)
B>>{
B>>    Starter (More, Less)
B>>    New  Event More{Condition=:I<J Connection.Add (| I.Chang, J.Change) Sub{J:=J-I}
B>>    New  Event Less  {Condition=:I<J Connection.Add (| I.Chang, J.Change ) Sub{I:=I-J}
B>>    Public Event Eq {Condition=:I=J Connection.Add (| I.Chang, J.Change ) Sub{Nod.Off}
B>>}
B>>

B>>Выполнение оператора Off влечет за собой одноименное событие. Автомат может выключить себя сам, а возможно это сделать и вне автомата методом Off. Такая схема позволяет запустить на выполнение несколько автоматов и синхронизировать их выполнение событиями.

M>Хотелось бы увидеть это на примере.

B>>Данный автомат останавливается самостоятельно после вычисления. Кроме того внешнее событие Eq может послужить для информирования о готовности вычисления.

B>>Синхронизация с событием Eq, и выключение автомата Nod.
B>>

B>>Dim Integer (A=5, B=35)
B>>New Nod AV (A, B)                         'Создание автомата Nod
B>>AV.OnStart                                'Включение одновременно со стартером.
B>>Event {Connection=:AV.Eq}                 'Оператор синхронизации. Здесь выполнение программы остановится ожидая события AV.Eq
B>>Nod.Stop                                  'Выключение автомата Nod
B>>

M>Выделенное — это очень плохо. Программисту придется лавировать между событиями, которые создают узкие места в программе на ровном месте.
Никаких узких мест. Выполнение остановилось и ждет события AV.Eq
Заметь это тот же объект класса Event который в ранее приведеных примерах создавался оператором New, но статический и находится в теле документа.

B>>И пример логического разбора. Интерпретации. Определим следующие предикаты.

B>>

B>>Predicate 
B>>  {
B>>     Positive (X: Integer) {Positive=X>0} ' Предикат  Positive
B>>     Четное (X: Integer) {Здесь проверка на четность. Знак операции И не проходит}
B>>  }
B>>

B>>Теперь определим множество, на котором будет выполняться интерпретация. В нашем случае это множества целых чисел и объекты-значения I и Y.
B>>Dim Integer (I=-50000, Y=108)
B>>Высказывание со знаком вопроса называется целевым высказыванием. Этот знак запускает не императивное вычисление, а осуществляет попытку логического разбора. Определим целевое высказывание.
B>>If Positive (I ^ Y)?
B>>Сейчас мы покажем как можно решить эту задачу без возведения в 108 степень. Для этого определим следующие высказывания на множестве Integer и Positiv.
B>>

B>>Utterance
B>>{
B>>    ForAll (А: Integer, B: Positive) ‹Positive (A)  Positive (A^B) ›
B>>    ForAll (А: Integer, B: Positive)‹Четное (B)  Positive (A^B) ›
B>>}
B>>

B>>Знак "следует" здесь не прошел. На его месте квадратик.

M>Естественно. Именно поэтому весь цивилизованный мир не использует странные символы в программах. Печальный опыт APL был не зря.
Мне кажется что с тех пор кое что изменилось и в редакторах и средствах редактирования. Имхо, но готов обсудить.

B>>Замечу, что в качестве параметров могут быть не только объекты классов или типов, но и объекты принадлежащие множеству или принадлежащие множеству определенному предикатом, как в нашем примере(Positive).

M>Это называется, в частности, duck typing (утиная типизация).
Да. Это оно. Спасибо. Не знал.

M>Ну, это понятно. Prolog в качестве DSL'я для языка. Понятно, так понятно. Это лучше чем не понятно.. Хотя ХЗ.

M>Тьфу, елки

Даже ссылки приводил. Кратко: публичный онлайн репозиторий кода. Надеюсь, не надо объяснять, что такое репозиторий и контроль версий?
Сейчас не надо. Как созрею обращусь.

M>Просто выбор никого не интересует. Более тго, для этого есть Лисп

Людей интересует именно «лучшесть». Насколько более эффективно новый язык позволит решать те или иные задачи.
Есть обоснованное подозрение, что моя схема будет легче транслироваться и выполняться за счет унификации и малого числа базовых определений. Хотя бы потому что вся эта кухня легко влезет в кэш. Но, кроме подозрений пока ничего не могу сказать. Есть вариант обработчик событий сделать аппаратно. Он вполне может выполняься параллельно. Но это опять таки..в будущем.

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

E__>>>Ок. Это понятно. В принципе, звучит толково.

E__>>>Ждем дальше, глядишь, по чуть-чуть разберем остальные аспекты языка.
B>>Спасибо. Смотрю так в диалоге лучше получается чем документ вывалить. Тогда я позволю о группах объяснится. Это принципиальная часть и касается работы виртуальной машины. К сожалению подстрочные и надстрочные знаки я не могу здесь проставить, но надеюсь будет понятно. Хотя лажа, конечно.

M>Лажа — это использование символов, которые нельзя без приседаний воспроизвести на клавиатуре.
Так эта лажа и так есть. Я вот не могу здесь двойные угловые текстовые скобки найти. Необходим другой подход. Давай это оставим на потом. От развития никуда не денешься. Знаков будет только больше. Так что если не мы придумаем, то кто-то другой придумает. Единственный вопрос кто будет первым. Проблем с буквами и знаками реально много. Просто это отдельная тема.

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

B>>Спасибо. Смотрю так в диалоге лучше получается чем документ вывалить. Тогда я позволю о группах объяснится. Это принципиальная часть и касается работы виртуальной машины. К сожалению подстрочные и надстрочные знаки я не могу здесь проставить, но надеюсь будет понятно. Хотя лажа, конечно.

M>Вторая лажа — придумывание собственных терминов.
ОБСУЖДАЕМО.

B>>Группирование объектов допускается двумя способами с последовательным выполнением группы и произвольным выполнением группы (классы Tape и Group).

M>Если и то и другое группа, почему только одна называется группой? Почему не Sequence(SeqGroup) и Random(RndGroup)? Зачем нуны пляски с приседанием в виде толпы разных скобок? Которые еще и близки визуально.
Произвольное выполнение и последовательное существует независимо от того хотим мы этого или нет. Единственно, что я сделал так это строго привязал назначение скобок. Отличие между круглыми и фигурными только в том что объекты в круглых скобках необходимо разделять запятыми. Это чисто для удобства. Кому как удобней пусть так и определяет. Приятно, что это правило действует везде.

B>> Группирование с последовательным выполнением. Класс Tape.
B>>Пример 1. Присвоение свойствам группы Word значений Min=2 и Max=40
B>>Word {Letter}2 40

M>Или
M>

M>Word Sequence(Letter)[2,40]
M>

B>>Данная группа выполняется максимум 40 раз, но для ее успешного выполнения достаточно одного успешного выполнения группы.
И зачем тут скобки? Надстрочное и подстрочное выглядит наглядней. Применение скобок надо-не надо не всегда самый мудрый способ. Аналогично как и перегрузка знаками обозначающими все что не заблагорассудилось разрабочику.

M>Ах, да:

M>

M>Determination Модификатор [. «Private» «Public» «Protected»]
M>

M>determination

M>1) решительность; решимость
M>2) решение, разрешение (спора)
M>3) юр. определение, постановление (суда)
M>4) определение; установление, задание, фиксирование
M>5) книжн. стремление, тенденция (к чему-л.) ; пристрастие (к чему-л.)
M>6) мед. прилив (крови)

M>При том, что весь мир использует для понятия «определение» слово "define"

ЗАМЕЧАНИЕ ПРИНИМАЕТСЯ ОДНОЗНАЧНО! СПАСИБО!

M>> операторы у меня тоже объекты и могут иметь имена и оператор, например Exit указывает имя объекта-оператора (а может и класса) из которого необходимо выйти. Получается например такая картина.
M>>For i=0 to n
M>>...
M>>Exit I

M>>То в операторе Exit I-это имя оператора For, а не имя переменной.
M>>[/q]

M>>Что это за примеры? ЧТо это все значит? Какая практическая в них необходимость? Как их применять? На эти вопросы нет ни единого ответа.
B>Пока нет ответа. Сейчас попробую дать. Вот оператор For это объект класса For с именем и т.д.. Это мы пишем программу. Она же является документом. Т.е. это частный случай документа, который мы можем наполнить и формами, и вообще объектами любого классса. Т.е. ниже приведенный код

B>

B>Form Первый
B>  { Me.Size=20;80
B>    TextBox {}
B>    Button { Me.Text="Start" ...}
B>  }
B>

B>Это просто форма с текстбоксом и кнопкой..
B>Если мы применяем к этой форме оператор New, то эта форма создастся (и разместиться в памяти) динамически во время выполнения.

B>

B>New Form Первый
B>  { Me.Size=20;80
B>    TextBox {}
B>    Button { Me.Text="Start" ...}
B>  }
B>

B>Вот в таком виде мы обычно и используем объекты в программе.
B>Так вот зачем так много слов про этот Exit и про имя, а дело в том, что адрес объекта к которому необходимо обратиться находится в теле документа, а не формируется через заголовок процедуры (в силу динамического размещения), так как происходит в случае обращения к объектам созданым опреторами Dim и New. Просто я напоминаю что это не только язык программирвания, но и язык документирования. Для анализа объектов в теле документа адресация осуществляется так называемым указателем и там немного другой принцип. Вот оператор Exit это частный случай такого указателя (Pointer).

Выделенное не понятно вообще.

B>>>Данный автомат останавливается самостоятельно после вычисления. Кроме того внешнее событие Eq может послужить для информирования о готовности вычисления.

B>>>Синхронизация с событием Eq, и выключение автомата Nod.
B>>>

B>>>Dim Integer (A=5, B=35)
B>>>New Nod AV (A, B)                         'Создание автомата Nod
B>>>AV.OnStart                                'Включение одновременно со стартером.
B>>>Event {Connection=:AV.Eq}                 'Оператор синхронизации. Здесь выполнение программы остановится ожидая события AV.Eq
B>>>Nod.Stop                                  'Выключение автомата Nod
B>>>

M>>Выделенное — это очень плохо. Программисту придется лавировать между событиями, которые создают узкие места в программе на ровном месте.
B>Никаких узких мест. Выполнение остановилось и ждет события AV.Eq

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

B>>>Знак "следует" здесь не прошел. На его месте квадратик.

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

Что обсуждать? Посмотри на клавиатуру и найди мне там знак «следует». Запоминать комбинации клавиш для десятка математических знаков или тянутся на каждый чих мышкой к соответствующей иконке никто не будет.

B>>>Замечу, что в качестве параметров могут быть не только объекты классов или типов, но и объекты принадлежащие множеству или принадлежащие множеству определенному предикатом, как в нашем примере(Positive).

M>>Это называется, в частности, duck typing (утиная типизация).
B>Да. Это оно. Спасибо. Не знал.

Вообще-то при разработке нового языка подразумевается, что автор ознакомился с наработками в других языках, не?

M>>Просто выбор никого не интересует. Более тго, для этого есть Лисп

Людей интересует именно «лучшесть». Насколько более эффективно новый язык позволит решать те или иные задачи.
B>Есть обоснованное подозрение, что моя схема будет легче транслироваться и выполняться за счет унификации и малого числа базовых определений.

Обосновано чем? Малое число базовых определений? Ты смеешься

Только в этом ткст у тебя уже были Оператор, Класс, Объект класса, логическое программирование, ггруппировки двумя типами и т.п.

B>Хотя бы потому что вся эта кухня легко влезет в кэш.

В какой кэш?

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

Вообще-то, весб мир знает, что события должны быть асинхронными

И что синхронные события нужны только в очень малом количестве случаев

B>>> К сожалению подстрочные и надстрочные знаки я не могу здесь проставить, но надеюсь будет понятно. Хотя лажа, конечно.

M>>Лажа — это использование символов, которые нельзя без приседаний воспроизвести на клавиатуре.
B>Так эта лажа и так есть. Я вот не могу здесь двойные угловые текстовые скобки найти. Необходим другой подход. Давай это оставим на потом. От развития никуда не денешься. Знаков будет только больше. Так что если не мы придумаем, то кто-то другой придумает. Единственный вопрос кто будет первым. Проблем с буквами и знаками реально много. Просто это отдельная тема.

Вообще-то, это не отдельная тема и ее нельзя оставлять на потом. Или будешь плодить десяток версии с несовместимым синтаксисом? И зачем больше знаков? Не плоди сущностей без необходимости.

B>>>Группирование объектов допускается двумя способами с последовательным выполнением группы и произвольным выполнением группы (классы Tape и Group).

M>>Если и то и другое группа, почему только одна называется группой? Почему не Sequence(SeqGroup) и Random(RndGroup)? Зачем нуны пляски с приседанием в виде толпы разных скобок? Которые еще и близки визуально.
B>Произвольное выполнение и последовательное существует независимо от того хотим мы этого или нет. Единственно, что я сделал так это строго привязал назначение скобок.

Зачем? У программиста есть лучше занятия, чем в большом куске кода следить за разницей между ([{, которые похожу друг на друга.

B>Отличие между круглыми и фигурными только в том что объекты в круглых скобках необходимо разделять запятыми. Это чисто для удобства.

Для какого удобства? Теперь программисту еще надо помнить, что в одних скобках надо ставить запятые, а в других не надо? Только потому что автору зяыка вдруг так захотелось?

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

Идиотское правило. почему в круглых скобках надо разделять запятыми, а в квадратных и фигурных не надо?

B>>> Группирование с последовательным выполнением. Класс Tape.
B>>>Пример 1. Присвоение свойствам группы Word значений Min=2 и Max=40
B>>>Word {Letter}2 40

M>>Или
M>>

M>>Word Sequence(Letter)[2,40]
M>>

B>>>Данная группа выполняется максимум 40 раз, но для ее успешного выполнения достаточно одного успешного выполнения группы.
B>И зачем тут скобки? Надстрочное и подстрочное выглядит наглядней.

Посмотри на клавиатуру и найди мне под- и надстрочные знаки.

B>Применение скобок надо-не надо не всегда самый мудрый способ.

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

B>>>> Группирование с последовательным выполнением. Класс Tape.
B>>>>Пример 1. Присвоение свойствам группы Word значений Min=2 и Max=40
B>>>>Word {Letter}2 40

M>>>Или
M>>>

M>>>Word Sequence(Letter)[2,40]
M>>>

B>>>>Данная группа выполняется максимум 40 раз, но для ее успешного выполнения достаточно одного успешного выполнения группы.
B>>И зачем тут скобки? Надстрочное и подстрочное выглядит наглядней.

M>Посмотри на клавиатуру и найди мне под- и надстрочные знаки.

B>>Применение скобок надо-не надо не всегда самый мудрый способ.

M>Надо. И это в данной ситуации самый мудрый способ (более того, напоминающий аналогичный способ в регулярных выражениях). Никто никогда не будет ломать пальцы или постоянно тянуться за мышкой, чтобы набрать символ, которого нет на клавиатуре.

на самом деле есть еще вариант

Word Sequence(Leter, Min=2, Max=40)

Это все равно лучше, чем над- и подстрочные знаки.

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

M>>>Что это за примеры? ЧТо это все значит? Какая практическая в них необходимость? Как их применять? На эти вопросы нет ни единого ответа.
B>>Пока нет ответа. Сейчас попробую дать. Вот оператор For это объект класса For с именем и т.д.. Это мы пишем программу. Она же является документом. Т.е. это частный случай документа, который мы можем наполнить и формами, и вообще объектами любого классса. Т.е. ниже приведенный код

B>>

B>>Form Первый
B>>  { Me.Size=20;80
B>>    TextBox {}
B>>    Button { Me.Text="Start" ...}
B>>  }
B>>

B>>Это просто форма с текстбоксом и кнопкой..
B>>Если мы применяем к этой форме оператор New, то эта форма создастся (и разместиться в памяти) динамически во время выполнения.

B>>

B>>New Form Первый
B>>  { Me.Size=20;80
B>>    TextBox {}
B>>    Button { Me.Text="Start" ...}
B>>  }
B>>

B>>Вот в таком виде мы обычно и используем объекты в программе.
B>>Так вот зачем так много слов про этот Exit и про имя, а дело в том, что адрес объекта к которому необходимо обратиться находится в теле документа, а не формируется через заголовок процедуры (в силу динамического размещения), так как происходит в случае обращения к объектам созданым опреторами Dim и New. Просто я напоминаю что это не только язык программирвания, но и язык документирования. Для анализа объектов в теле документа адресация осуществляется так называемым указателем и там немного другой принцип. Вот оператор Exit это частный случай такого указателя (Pointer).

M>Выделенное не понятно вообще.
Вопрос. С ассемблером знаком? Как формируются адреса переменных, как передаются параметры в процедурах? Мне нужно знать откуда начинать рассказывать.

B>>>>Данный автомат останавливается самостоятельно после вычисления. Кроме того внешнее событие Eq может послужить для информирования о готовности вычисления.

B>>>>Синхронизация с событием Eq, и выключение автомата Nod.
B>>>>

B>>>>Dim Integer (A=5, B=35)
B>>>>New Nod AV (A, B)                         'Создание автомата Nod
B>>>>AV.OnStart                                'Включение одновременно со стартером.
B>>>>Event {Connection=:AV.Eq}                 'Оператор синхронизации. Здесь выполнение программы остановится ожидая события AV.Eq
B>>>>Nod.Stop                                  'Выключение автомата Nod
B>>>>

M>>>Выделенное — это очень плохо. Программисту придется лавировать между событиями, которые создают узкие места в программе на ровном месте.
B>>Никаких узких мест. Выполнение остановилось и ждет события AV.Eq

M>Выделенное и есть узкое место. В итоге, если мы будем останавливаться на каждое событие, разработчик не сможет написать ничего сложного. Потому что программа постоянно будет останавливаться то там то тут в ожидании событий.
Автомат работает параллельно. Посмотри на класс. Объект-автомат начинает работу со старта. Работа автомата заключается в срабатывании событий. (это работает почти как сети Петри, но пришлось придумать свои сети они лучше подходят для моих событий) и заканчивает работу при возникновении события EQ. Если нас интересует результат работы автомата, то необходимо подождать, когда возникнет состояние автмата Eq. а можно и не ждать. Запустить с десяток автоматов и ловить события в любом другом месте просто создав новое событие оператором New и связав его с ожидаемым Eq. (Обратил ли внимание что наше событие не создавалось оператором New?) Я не пойму что страшного ты увидел в остановке для синхронизации? Обычное дело. Правда, обычно мы не останавливаемся для ожидания результата. События создаваемые автоматом можно перехватывать и без остановки. Просто в этом конкретном случае можно и остановится.

B>>>>Знак "следует" здесь не прошел. На его месте квадратик.

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

M>Что обсуждать? Посмотри на клавиатуру и найди мне там знак «следует». Запоминать комбинации клавиш для десятка математических знаков или тянутся на каждый чих мышкой к соответствующей иконке никто не будет.
можно мы не будем про клавиатуру? Есть клавиатура Лебедева, есть тачскрины. Да мало ли какие еще варианты есть.. И я это продумал.

M>Вообще-то при разработке нового языка подразумевается, что автор ознакомился с наработками в других языках, не?
Получается я и сам могу придумать кое-что.. Кстати, не только это.

Но MS быстро догоняет. Хотя все равно приятно видеть там свои задумки. Ladу не догонят. На такие изменения они не пойдут. Им и так хорошо.

M>Обосновано чем? Малое число базовых определений? Ты смеешься

Только в этом ткст у тебя уже были Оператор, Класс, Объект класса, логическое программирование, группировки двумя типами и т.п.
Не смеюсь.

B>>Хотя бы потому что вся эта кухня легко влезет в кэш.

M>В какой кэш?
Кэш процессора.

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

M>Вообще-то, весб мир знает, что события должны быть асинхронными

И что синхронные события нужны только в очень малом количестве случаев.
Я не спорю с миром. С чего ты решил что я возражаю

Наоборот. Выделение событий таким образом позволяет распараллелить даже саму работу диспетчера событий.

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

B>>>> К сожалению подстрочные и надстрочные знаки я не могу здесь проставить, но надеюсь будет понятно. Хотя лажа, конечно.

M>>>Лажа — это использование символов, которые нельзя без приседаний воспроизвести на клавиатуре.
B>>Так эта лажа и так есть. Я вот не могу здесь двойные угловые текстовые скобки найти. Необходим другой подход. Давай это оставим на потом. От развития никуда не денешься. Знаков будет только больше. Так что если не мы придумаем, то кто-то другой придумает. Единственный вопрос кто будет первым. Проблем с буквами и знаками реально много. Просто это отдельная тема.

M>Вообще-то, это не отдельная тема и ее нельзя оставлять на потом. Или будешь плодить десяток версии с несовместимым синтаксисом? И зачем больше знаков? Не плоди сущностей без необходимости.
Есть знаки не равно, меньше или равно, больше и равно. Кванторы И, Или. Знак Нет. А как тебя не удивляло отсутствие знаков True и False? Ведь цирк! Кто Yes, No пишет. В математической литературе обозначают буквами f, t. Кто во что горазд. А ведь давно надо бы придумать. Да и знаки форматирования тоже ждут не дождуться.. Вообщем там конь не валялся.

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

B>>>>Группирование объектов допускается двумя способами с последовательным выполнением группы и произвольным выполнением группы (классы Tape и Group).

M>>>Если и то и другое группа, почему только одна называется группой? Почему не Sequence(SeqGroup) и Random(RndGroup)? Зачем нуны пляски с приседанием в виде толпы разных скобок? Которые еще и близки визуально.
B>>Произвольное выполнение и последовательное существует независимо от того хотим мы этого или нет. Единственно, что я сделал так это строго привязал назначение скобок.

M>Зачем? У программиста есть лучше занятия, чем в большом куске кода следить за разницей между ([{, которые похожу друг на друга.

B>>Отличие между круглыми и фигурными только в том что объекты в круглых скобках необходимо разделять запятыми. Это чисто для удобства.

M>Для какого удобства? Теперь программисту еще надо помнить, что в одних скобках надо ставить запятые, а в других не надо? Только потому что автору зяыка вдруг так захотелось?
Здесь обратная логика. Можно писать и так и так. Однопупственно. Но если с точки зрения наглядности будет удобнее разделить запятыми, то используются круглые скобки (например параметры процедуры), а если запятые только мешают то используем фигурные (например операторы в теле цикла).

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

M>Идиотское правило. почему в круглых скобках надо разделять запятыми, а в квадратных и фигурных не надо?

B>>>> Группирование с последовательным выполнением. Класс Tape.
B>>>>Пример 1. Присвоение свойствам группы Word значений Min=2 и Max=40
B>>>>Word {Letter}2 40

M>>>Или
M>>>

M>>>Word Sequence(Letter)[2,40]
M>>>

B>>>>Данная группа выполняется максимум 40 раз, но для ее успешного выполнения достаточно одного успешного выполнения группы.
B>>И зачем тут скобки? Надстрочное и подстрочное выглядит наглядней.

M>Посмотри на клавиатуру и найди мне под- и надстрочные знаки.

B>>Применение скобок надо-не надо не всегда самый мудрый способ.

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

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

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

M>>Что такое NOD?
B>НОД по русски.. Школа.. арифметика.

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

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

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

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

M>>>Что такое NOD?
B>>НОД по русски.. Школа.. арифметика.

К>По-английски он будет GCD, выглядит странно: значки извратные вносим, а русскоязычные термины пишем латиницей. Как-то ну очень последовательно

Это да. Не хорошая традиция

B>>>Вот в таком виде мы обычно и используем объекты в программе.
B>>>Так вот зачем так много слов про этот Exit и про имя, а дело в том, что адрес объекта к которому необходимо обратиться находится в теле документа, а не формируется через заголовок процедуры (в силу динамического размещения), так как происходит в случае обращения к объектам созданым опреторами Dim и New. Просто я напоминаю что это не только язык программирвания, но и язык документирования. Для анализа объектов в теле документа адресация осуществляется так называемым указателем и там немного другой принцип. Вот оператор Exit это частный случай такого указателя (Pointer).

M>>Выделенное не понятно вообще.
B>Вопрос. С ассемблером знаком? Как формируются адреса переменных, как передаются параметры в процедурах? Мне нужно знать откуда начинать рассказывать.

Давай, ты просто внятно объяснишь, а?

B>>>>>Данный автомат останавливается самостоятельно после вычисления. Кроме того внешнее событие Eq может послужить для информирования о готовности вычисления.

B>>>>>Синхронизация с событием Eq, и выключение автомата Nod.
B>>>>>

B>>>>>Dim Integer (A=5, B=35)
B>>>>>New Nod AV (A, B)                         'Создание автомата Nod
B>>>>>AV.OnStart                                'Включение одновременно со стартером.
B>>>>>Event {Connection=:AV.Eq}                 'Оператор синхронизации. Здесь выполнение программы остановится ожидая события AV.Eq
B>>>>>Nod.Stop                                  'Выключение автомата Nod
B>>>>>

M>>>>Выделенное — это очень плохо. Программисту придется лавировать между событиями, которые создают узкие места в программе на ровном месте.
B>>>Никаких узких мест. Выполнение остановилось и ждет события AV.Eq

M>>Выделенное и есть узкое место. В итоге, если мы будем останавливаться на каждое событие, разработчик не сможет написать ничего сложного. Потому что программа постоянно будет останавливаться то там то тут в ожидании событий.
B>Автомат работает параллельно. Посмотри на класс. Объект-автомат начинает работу со старта. Работа автомата заключается в срабатывании событий. (это работает почти как сети Петри, но пришлось придумать свои сети они лучше подходят для моих событий) и заканчивает работу при возникновении события EQ. Если нас интересует результат работы автомата, то необходимо подождать, когда возникнет состояние автмата Eq. а можно и не ждать. Запустить с десяток автоматов и ловить события в любом другом месте просто создав новое событие оператором New и связав его с ожидаемым Eq. (Обратил ли внимание что наше событие не создавалось оператором New?) Я не пойму что страшного ты увидел в остановке для синхронизации? Обычное дело. Правда, обычно мы не останавливаемся для ожидания результата. События создаваемые автоматом можно перехватывать и без остановки. Просто в этом конкретном случае можно и остановится.

Это и есть толпа узких мест на пустом месте. Повторяю еще раз, максимально простым языком: события должны быть асинхронными. Потому что блокировка любой точки программы для ожидания — это узкое место.

B>>>>>Знак "следует" здесь не прошел. На его месте квадратик.

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

M>>Что обсуждать? Посмотри на клавиатуру и найди мне там знак «следует». Запоминать комбинации клавиш для десятка математических знаков или тянутся на каждый чих мышкой к соответствующей иконке никто не будет.
B>можно мы не будем про клавиатуру? Есть клавиатура Лебедева, есть тачскрины. Да мало ли какие еще варианты есть.. И я это продумал.

Причем тут клавиатура Лебедева и тачскрины? Даже на них количество символов ограничено. Никто не будет прыгать туда-сюда с модификаторами клавиш, пытаясь найти нужный символ.

M>>Вообще-то при разработке нового языка подразумевается, что автор ознакомился с наработками в других языках, не?
B>Получается я и сам могу придумать кое-что.. Кстати, не только это.

Но MS быстро догоняет. Хотя все равно приятно видеть там свои задумки. Ladу не догонят. На такие изменения они не пойдут. Им и так хорошо.

M>>Обосновано чем? Малое число базовых определений? Ты смеешься

Только в этом ткст у тебя уже были Оператор, Класс, Объект класса, логическое программирование, группировки двумя типами и т.п.
B>Не смеюсь.

Не заметно. У тебя огромное количество определений.

B>>>Хотя бы потому что вся эта кухня легко влезет в кэш.

M>>В какой кэш?
B>Кэш процессора.

И у тебя, наверное, есть цифры, это подтвреждающие?

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

M>>Вообще-то, весб мир знает, что события должны быть асинхронными

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

Наоборот. Выделение событий таким образом позволяет распараллелить даже саму работу диспетчера событий.

Угу. И при этом выше ты говоришь, что приложение (или блок кода — неважно) должно отсанавливаться и ждать выполнение события

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

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

B>>>>> К сожалению подстрочные и надстрочные знаки я не могу здесь проставить, но надеюсь будет понятно. Хотя лажа, конечно.

M>>>>Лажа — это использование символов, которые нельзя без приседаний воспроизвести на клавиатуре.
B>>>Так эта лажа и так есть. Я вот не могу здесь двойные угловые текстовые скобки найти. Необходим другой подход. Давай это оставим на потом. От развития никуда не денешься. Знаков будет только больше. Так что если не мы придумаем, то кто-то другой придумает. Единственный вопрос кто будет первым. Проблем с буквами и знаками реально много. Просто это отдельная тема.

M>>Вообще-то, это не отдельная тема и ее нельзя оставлять на потом. Или будешь плодить десяток версии с несовместимым синтаксисом? И зачем больше знаков? Не плоди сущностей без необходимости.
B>Есть знаки не равно,

!=

B>меньше или равно,

<=

B>больше и равно.

>=

B>Кванторы И

and

B>, Или.

or

B>Знак Нет.

not

B>А как тебя не удивляло отсутствие знаков True и False? Ведь цирк! Кто Yes, No пишет. В математической литературе обозначают буквами f, t. Кто во что горазд. А ведь давно надо бы придумать.

уже давно придумали. используется true/false

B>Да и знаки форматирования тоже ждут не дождуться.. Вообщем там конь не валялся.

И не надо ему нигде валяться. Все, что тебе кажется непридуманным, уже придумано. Более того, клавиатура не безгранична. И, повторю, никто не будет ломать пальцы, запоминать модификаторы и т.п., пытаясь это все набрать. Блин. В тертий раз говорю. Был такой язык APL, окторый пытался сделать то же, что и ты — ввести хитрый символ на каждый чих. Нет, чтобы посмотреть на проблемы которые были с этим связаны

B>>>>>Группирование объектов допускается двумя способами с последовательным выполнением группы и произвольным выполнением группы (классы Tape и Group).

M>>>>Если и то и другое группа, почему только одна называется группой? Почему не Sequence(SeqGroup) и Random(RndGroup)? Зачем нуны пляски с приседанием в виде толпы разных скобок? Которые еще и близки визуально.
B>>>Произвольное выполнение и последовательное существует независимо от того хотим мы этого или нет. Единственно, что я сделал так это строго привязал назначение скобок.

M>>Зачем? У программиста есть лучше занятия, чем в большом куске кода следить за разницей между ([{, которые похожу друг на друга.

B>>>Отличие между круглыми и фигурными только в том что объекты в круглых скобках необходимо разделять запятыми. Это чисто для удобства.

M>>Для какого удобства? Теперь программисту еще надо помнить, что в одних скобках надо ставить запятые, а в других не надо? Только потому что автору зяыка вдруг так захотелось?
B>Здесь обратная логика. Можно писать и так и так. Однопупственно. Но если с точки зрения наглядности будет удобнее разделить запятыми, то используются круглые скобки (например параметры процедуры), а если запятые только мешают то используем фигурные (например операторы в теле цикла).

Что занчит с точки зрения наглядности? Ты тут что-то говорил об унифицированности. И тут — ВНЕЗАПНО — никакой унификации.

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

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

Нет, не легко

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

B>>>>Хотя бы потому что вся эта кухня легко влезет в кэш.

M>>>В какой кэш?
B>>Кэш процессора.

M>И у тебя, наверное, есть цифры, это подтвреждающие?

+ ещё вопрос — какого процессора кэш?
Язык только под x86 (возможно, и только по Windows)?

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

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

B>>Да и знаки форматирования тоже ждут не дождуться.. Вообщем там конь не валялся.

M>И не надо ему нигде валяться. Все, что тебе кажется непридуманным, уже придумано. Более того, клавиатура не безгранична. И, повторю, никто не будет ломать пальцы, запоминать модификаторы и т.п., пытаясь это все набрать. Блин. В тертий раз говорю. Был такой язык APL, окторый пытался сделать то же, что и ты — ввести хитрый символ на каждый чих. Нет, чтобы посмотреть на проблемы которые были с этим связаны

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

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

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

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

B>>>>>> К сожалению подстрочные и надстрочные знаки я не могу здесь проставить, но надеюсь будет понятно. Хотя лажа, конечно.

M>>>>>Лажа — это использование символов, которые нельзя без приседаний воспроизвести на клавиатуре.
B>>>>Так эта лажа и так есть. Я вот не могу здесь двойные угловые текстовые скобки найти. Необходим другой подход. Давай это оставим на потом. От развития никуда не денешься. Знаков будет только больше. Так что если не мы придумаем, то кто-то другой придумает. Единственный вопрос кто будет первым. Проблем с буквами и знаками реально много. Просто это отдельная тема.

M>>>Вообще-то, это не отдельная тема и ее нельзя оставлять на потом. Или будешь плодить десяток версии с несовместимым синтаксисом? И зачем больше знаков? Не плоди сущностей без необходимости.
B>>Есть знаки не равно,

M>!=
Есть перечеркнутое равенство. И выпендреж.
B>>меньше или равно,

M><=

Одним знаком
B>>больше и равно.

>>=

B>>Кванторы И

M>and

Есть знак. А это текст
B>>, Или.

M>or
Есть знак. А это текст
B>>Знак Нет.

M>not
Есть знак. А это текст

B>>А как тебя не удивляло отсутствие знаков True и False? Ведь цирк! Кто Yes, No пишет. В математической литературе обозначают буквами f, t. Кто во что горазд. А ведь давно надо бы придумать.

M>уже давно придумали. используется true/false
А почему бы знаки не придумать? По моему назрело.

B>>Да и знаки форматирования тоже ждут не дождуться.. Вообщем там конь не валялся.

M>И не надо ему нигде валяться. Все, что тебе кажется непридуманным, уже придумано. Более того, клавиатура не безгранична. И, повторю, никто не будет ломать пальцы, запоминать модификаторы и т.п., пытаясь это все набрать. Блин. В тертий раз говорю. Был такой язык APL, окторый пытался сделать то же, что и ты — ввести хитрый символ на каждый чих. Нет, чтобы посмотреть на проблемы которые были с этим связаны

хитрый символ на каждый чих это ни к чему. И даже глупо. А вот использовать общепринятые можно и нужно. Если ты не согласен давай на этом прекратим. Хотя бы на время. Что б не засорять тему. Пусть она остынет..

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

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

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

B>>>Да и знаки форматирования тоже ждут не дождуться.. Вообщем там конь не валялся.

M>>И не надо ему нигде валяться. Все, что тебе кажется непридуманным, уже придумано. Более того, клавиатура не безгранична. И, повторю, никто не будет ломать пальцы, запоминать модификаторы и т.п., пытаясь это все набрать. Блин. В тертий раз говорю. Был такой язык APL, окторый пытался сделать то же, что и ты — ввести хитрый символ на каждый чих. Нет, чтобы посмотреть на проблемы которые были с этим связаны

B>хитрый символ на каждый чих это ни к чему. И даже глупо. А вот использовать общепринятые можно и нужно. Если ты не согласен давай на этом прекратим. Хотя бы на время. Что б не засорять тему. Пусть она остынет..

К сведенью (по твоим постам складывается очень стойкое ощущение, что в содержание реплик твоих оппонентов ты очень слабо вчитываешься

), в APL как раз и были общепринятые (математические), глянь хотяб апльную клавиатуру из вики.
Так что Дима тут не очень прав — в APL был вполне конкретный (и продуманный, Айверсон язык не в качестве шутки разрабатывал) "словарик" символов (в том же наследнике APL J он так и называется — Vocabulary, но используется ASCII-набор), никаких "на каждый чих".

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

B>>Здесь обратная логика. Можно писать и так и так. Однопупственно. Но если с точки зрения наглядности будет удобнее разделить запятыми, то используются круглые скобки (например параметры процедуры), а если запятые только мешают то используем фигурные (например операторы в теле цикла).

M>Что занчит с точки зрения наглядности? Ты тут что-то говорил об унифицированности. И тут — ВНЕЗАПНО — никакой унификации.

M>Наглядность — это, в первую очередь, принцип наименьшего удивления. Если и то и другое группировка, то с какого перепугу в одной используются запятые, а в другой — нет? Потому что зачесалась левая пятка автора языка?
Потому что есть выбор, хотя по сути это одно и тоже вот примеры.
а=(1, 2, 3, 4, 5)
If А
{ X+=5
Y-=6
f(J,Z)
}

Здесь группа операторов тела If-a прекрасно смотрятся без запятых, а при вызове функции как-то приятней разделить запятыми. Можно и наоборот написать. Только вряд ли это будет наглядней. Так что левая пятка старалась только для удобств пользователя.

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

M>Нет, не легко
Сравни правила регулярных выражений.здесь Вот где натыкали обозначений...
И мои.
Система Lada имеет собственные средства описания грамматики, поэтому в тексте использована именно эта нотация, краткое описание которой ниже.

1. Понятие определяется оператором Define, за которым следует имя определяемого понятия и далее определяющая последовательность понятий в скобках.
2. Имя определяемого понятия может содержать не больше сорока букв, либо любые знаки, заключенные в именные скобки «"». Более подробно смотри правила именования (Раздел 1).
3. При необходимости определить сразу несколько понятий они заключаются в фигурные скобки (либо в круглые скобки через запятую) после оператора Define. Раздел 2.1. Объекты, заключенные в скобки будем называть группой.
4. Последовательность знаков непосредственно участвующая в разборе выделяется текстовыми скобками ««» и «»». Пустая последовательность обозначается пустыми скобками «».
5. Объекты или группы разделенные знаком «|» означают выполнение одного из этих объектов или групп. Операция «Или».
6. Последовательность определений в скобках (группа), и знаком «|» после открывающей скобки (без пробела) обозначает выбор одного варианта из этой последовательности. Группа «Или».
7. Знак «¬» перед понятием (или группой понятий) означает, что в разборе допустимо все что угодно кроме этого понятия (или группы понятий). Операция «Нет».
8. Последовательность определений в скобках (группа), и знаком «¬» после открывающей скобки (без пробела) обозначает не совпадение ни с одним вариантом из этой последовательности. Группа «Нет».
9. Надстрочное значение, после закрывающей скобки определяет максимальное количество допустимых повторений понятий объединенных группой, которую закрывает эта скобка.
10. Подстрочное значение после группы понятий указывает минимальное количество вхождений данного понятия в определение. Значение 0 допускает отсутствие группы понятий в разборе.
11. Комментарий начинается со знака «'» и продолжается до конца строки.

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

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

M>>>Выделенное не понятно вообще.
B>>Вопрос. С ассемблером знаком? Как формируются адреса переменных, как передаются параметры в процедурах? Мне нужно знать откуда начинать рассказывать.

M>Давай, ты просто внятно объяснишь, а?

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

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

B>>>>>>Знак "следует" здесь не прошел. На его месте квадратик.

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

Про знаки оставим. Консенсуса не найдем. Я согласен что со стандартной клавиатурой будут неудобства. Ну, так на хитрую жопу найдется ...

M>Не заметно. У тебя огромное количество определений.

B>>>>Хотя бы потому что вся эта кухня легко влезет в кэш.

M>>>В какой кэш?
B>>Кэш процессора.

M>И у тебя, наверное, есть цифры, это подтвреждающие?

Есть. Я ж говорил что демка есть. В 64 кб влазит. Это и виртуальная машина и редактор и транслятор. До метра система не вырастет.

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

К>Так что Дима тут не очень прав — в APL был вполне конкретный (и продуманный, Айверсон язык не в качестве шутки разрабатывал) "словарик" символов (в том же наследнике APL J он так и называется — Vocabulary, но используется ASCII-набор), никаких "на каждый чих".
А с Ladой тут такая ситуация что много из ASCII становится лишним. Из управляющих нужны только начало объекта и конец. В остальном формат данных универсальный на основе класса. Кроме того коды вертикальной табуляции, перевода строки и т.д. концептуально являются событиями управлящими процессом редактирования, а не объектами для хранения и передачи данных. Передаются и хранятся объекты — буквы, знаки, лексемы, фразы, абзацы, разделы но не те действия которые привели к созданиям этих объектов. Ну, на заре компьютерной техники на такие нюансы не обращали внимания. Как и на то, что нет английской буквы "а" и русской буквы "а". Есть знак "а" который в разных языках ассоциируется в разные алфавиты. В тексте никогда не возникает вопрос "это русская буква Р?". Этот вопрос имеет смысл только в устной речи, когда необходимо установить обратную ассоциацию из алфавита в знак.

M>>>>Вообще-то, это не отдельная тема и ее нельзя оставлять на потом. Или будешь плодить десяток версии с несовместимым синтаксисом? И зачем больше знаков? Не плоди сущностей без необходимости.
B>>>Есть знаки не равно,

M>>!=
B>Есть перечеркнутое равенство. И выпендреж.
B>>>меньше или равно,

M>><=

B>Одним знаком

Почему обязательно одним знаком?

B>>>больше и равно.

>>>=

B>>>Кванторы И

M>>and

B>Есть знак. А это текст

Кого это волнует? никого, если оно точно выражает смысл. Более того, любой знак — это текст

B>>>, Или.

M>>or
B>Есть знак. А это текст

Кого это волнует? никого, если оно точно выражает смысл. Более того, любой знак — это текст

B>>>Знак Нет.

M>>not
B>Есть знак. А это текст

Кого это волнует? никого, если оно точно выражает смысл. Более того, любой знак — это текст

B>>>А как тебя не удивляло отсутствие знаков True и False? Ведь цирк! Кто Yes, No пишет. В математической литературе обозначают буквами f, t. Кто во что горазд. А ведь давно надо бы придумать.

M>>уже давно придумали. используется true/false
B>А почему бы знаки не придумать? По моему назрело.

Зачем их придумывать? Не плоди сущностей без необходимости.

B>>>Да и знаки форматирования тоже ждут не дождуться.. Вообщем там конь не валялся.

M>>И не надо ему нигде валяться. Все, что тебе кажется непридуманным, уже придумано. Более того, клавиатура не безгранична. И, повторю, никто не будет ломать пальцы, запоминать модификаторы и т.п., пытаясь это все набрать. Блин. В тертий раз говорю. Был такой язык APL, окторый пытался сделать то же, что и ты — ввести хитрый символ на каждый чих. Нет, чтобы посмотреть на проблемы которые были с этим связаны

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

Я вверху привел толпу (более-менее)общепринятых в программировании знаков

B>Если ты не согласен давай на этом прекратим. Хотя бы на время. Что б не засорять тему. Пусть она остынет..

Ты предлагаешь насадить в язык десяток непечатаемых и не всегда отображаемых знаков. Смысл, зачем это делать ты объяснить не можешь

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

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

B>>>Здесь обратная логика. Можно писать и так и так. Однопупственно. Но если с точки зрения наглядности будет удобнее разделить запятыми, то используются круглые скобки (например параметры процедуры), а если запятые только мешают то используем фигурные (например операторы в теле цикла).

M>>Что занчит с точки зрения наглядности? Ты тут что-то говорил об унифицированности. И тут — ВНЕЗАПНО — никакой унификации.

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

Выбор чего???.

B> вот примеры.
B> а=(1, 2, 3, 4, 5)
B>If А
B> { X+=5
B> Y-=6
B> f(J,Z)
B> }

B>Здесь группа операторов тела If-a прекрасно смотрятся без запятых, а при вызове функции как-то приятней разделить запятыми. Можно и наоборот написать. Только вряд ли это будет наглядней. Так что левая пятка старалась только для удобств пользователя.

Вот этот пример:

а = (1, 2, 3, 4, 5)
If A { X + 5, Y -= 6, f(J, Z)}

Нет такого, как "как-то приятнее". "Как-то приятнее" — это чес в левой пятке. Для удобства пользователя нужно единообразие. Повторю еще раз: Если и то и другое группировка, то с какого перепугу в одной используются запятые, а в другой — нет?

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

M>>Нет, не легко
B>Сравни правила регулярных выражений.здесь Вот где натыкали обозначений...
B>И мои.

Я не говорил об обозначениях. Я говоил о том, что правила разбора регулярных выражений вряд ли выразимы в терминах Лады или Ладой вообще.

B>Система Lada имеет собственные средства описания грамматики, поэтому в тексте использована именно эта нотация, краткое описание которой ниже.

B>1. Понятие определяется оператором Define, за которым следует имя определяемого понятия и далее определяющая последовательность понятий в скобках.
B>2. Имя определяемого понятия может содержать не больше сорока букв, либо любые знаки, заключенные в именные скобки «"». Более подробно смотри правила именования (Раздел 1).
B>3. При необходимости определить сразу несколько понятий они заключаются в фигурные скобки (либо в круглые скобки через запятую) после оператора Define. Раздел 2.1. Объекты, заключенные в скобки будем называть группой.
B>4. Последовательность знаков непосредственно участвующая в разборе выделяется текстовыми скобками ««» и «»». Пустая последовательность обозначается пустыми скобками «».
B>5. Объекты или группы разделенные знаком «|» означают выполнение одного из этих объектов или групп. Операция «Или».
B>6. Последовательность определений в скобках (группа), и знаком «|» после открывающей скобки (без пробела) обозначает выбор одного варианта из этой последовательности. Группа «Или».
B>7. Знак «¬» перед понятием (или группой понятий) означает, что в разборе допустимо все что угодно кроме этого понятия (или группы понятий). Операция «Нет».
B>8. Последовательность определений в скобках (группа), и знаком «¬» после открывающей скобки (без пробела) обозначает не совпадение ни с одним вариантом из этой последовательности. Группа «Нет».
B>9. Надстрочное значение, после закрывающей скобки определяет максимальное количество допустимых повторений понятий объединенных группой, которую закрывает эта скобка.
B>10. Подстрочное значение после группы понятий указывает минимальное количество вхождений данного понятия в определение. Значение 0 допускает отсутствие группы понятий в разборе.
B>11. Комментарий начинается со знака «'» и продолжается до конца строки.

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

Правильно, потому что регулярные выражения еще имеют backtarcking, references, поиск и возвращение групп символов и т.п.

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

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

M>>>>Выделенное не понятно вообще.
B>>>Вопрос. С ассемблером знаком? Как формируются адреса переменных, как передаются параметры в процедурах? Мне нужно знать откуда начинать рассказывать.

M>>Давай, ты просто внятно объяснишь, а?

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

Предположим, что знаю. Объясняй вот эту синтаксическую конструкцию:

Так вот зачем так много слов про этот Exit и про имя, а дело в том, что адрес объекта к которому необходимо обратиться находится в теле документа, а не формируется через заголовок процедуры (в силу динамического размещения), так как происходит в случае обращения к объектам созданым опреторами Dim и New.

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

Выделенное противоречит друг другу.

B>>>>>>>Знак "следует" здесь не прошел. На его месте квадратик.

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

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

Не надо искать хитрую жопу. Надо делать максимально просто.

M>>Не заметно. У тебя огромное количество определений.

B>>>>>Хотя бы потому что вся эта кухня легко влезет в кэш.

M>>>>В какой кэш?
B>>>Кэш процессора.

M>>И у тебя, наверное, есть цифры, это подтвреждающие?

B>Есть. Я ж говорил что демка есть. В 64 кб влазит. Это и виртуальная машина и редактор и транслятор. До метра система не вырастет.

И что? Как это относится к кэшу процессора? Правильно — никак

К>>Так что Дима тут не очень прав — в APL был вполне конкретный (и продуманный, Айверсон язык не в качестве шутки разрабатывал) "словарик" символов (в том же наследнике APL J он так и называется — Vocabulary, но используется ASCII-набор), никаких "на каждый чих".
B>А с Ladой тут такая ситуация что много из ASCII становится лишним. Из управляющих нужны только начало объекта и конец. В остальном формат данных универсальный на основе класса. Кроме того коды вертикальной табуляции, перевода строки и т.д. концептуально являются событиями управлящими процессом редактирования, а не объектами для хранения и передачи данных. Передаются и хранятся объекты — буквы, знаки, лексемы, фразы, абзацы, разделы но не те действия которые привели к созданиям этих объектов. Ну, на заре компьютерной техники на такие нюансы не обращали внимания. Как и на то, что нет английской буквы "а" и русской буквы "а". Есть знак "а" который в разных языках ассоциируется в разные алфавиты. В тексте никогда не возникает вопрос "это русская буква Р?". Этот вопрос имеет смысл только в устной речи, когда необходимо установить обратную ассоциацию из алфавита в знак.

Как это относится к контексту про непечатаемые и не отображаемые символы? Правильно, никак.

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

К>>>Так что Дима тут не очень прав — в APL был вполне конкретный (и продуманный, Айверсон язык не в качестве шутки разрабатывал) "словарик" символов (в том же наследнике APL J он так и называется — Vocabulary, но используется ASCII-набор), никаких "на каждый чих".
B>>А с Ladой тут такая ситуация что много из ASCII становится лишним. Из управляющих нужны только начало объекта и конец. В остальном формат данных универсальный на основе класса. Кроме того коды вертикальной табуляции, перевода строки и т.д. концептуально являются событиями управлящими процессом редактирования, а не объектами для хранения и передачи данных. Передаются и хранятся объекты — буквы, знаки, лексемы, фразы, абзацы, разделы но не те действия которые привели к созданиям этих объектов. Ну, на заре компьютерной техники на такие нюансы не обращали внимания. Как и на то, что нет английской буквы "а" и русской буквы "а". Есть знак "а" который в разных языках ассоциируется в разные алфавиты. В тексте никогда не возникает вопрос "это русская буква Р?". Этот вопрос имеет смысл только в устной речи, когда необходимо установить обратную ассоциацию из алфавита в знак.

M>Как это относится к контексту про непечатаемые и не отображаемые символы? Правильно, никак.
Прочитал твои замечания. Такое ощущуение что ты прикалываешься

К>>>>Так что Дима тут не очень прав — в APL был вполне конкретный (и продуманный, Айверсон язык не в качестве шутки разрабатывал) "словарик" символов (в том же наследнике APL J он так и называется — Vocabulary, но используется ASCII-набор), никаких "на каждый чих".
B>>>А с Ladой тут такая ситуация что много из ASCII становится лишним. Из управляющих нужны только начало объекта и конец. В остальном формат данных универсальный на основе класса. Кроме того коды вертикальной табуляции, перевода строки и т.д. концептуально являются событиями управлящими процессом редактирования, а не объектами для хранения и передачи данных. Передаются и хранятся объекты — буквы, знаки, лексемы, фразы, абзацы, разделы но не те действия которые привели к созданиям этих объектов. Ну, на заре компьютерной техники на такие нюансы не обращали внимания. Как и на то, что нет английской буквы "а" и русской буквы "а". Есть знак "а" который в разных языках ассоциируется в разные алфавиты. В тексте никогда не возникает вопрос "это русская буква Р?". Этот вопрос имеет смысл только в устной речи, когда необходимо установить обратную ассоциацию из алфавита в знак.

M>>Как это относится к контексту про непечатаемые и не отображаемые символы? Правильно, никак.
B>Прочитал твои замечания. Такое ощущуение что ты прикалываешься

Прикалываюсь с чего? Я, как программист, не понимаю, что может заставить меня постоянно прыгать по всей клавиатуре и/или использовать мышку для знаков, которых нет на клавиатуре и для написания которых требуются комбинации через Alt, Alt Gr или character map.

Я понимаю, что ≠ — это математический знак. Но весь мир спокойно использует != или аналоги, потому что без приседаний набрать его нельзя. То же относится к подавляющему большинству других знаков.

Другие замечания — вроде замечания про запятые — это не прикол, а реальный вопрос, на который внятного ответа так и не получено. Ну и т.п.

Здравствуйте, Mamut, Вы писали:
M>Прикалываюсь с чего? Я, как программист, не понимаю, что может заставить меня постоянно прыгать по всей клавиатуре и/или использовать мышку для знаков, которых нет на клавиатуре и для написания которых требуются комбинации через Alt, Alt Gr или character map.
Не, ну есть же люди, которые, например, используют типографскую раскладку — и везде ставят елочки, многоточия, длинные тире и т.п.

M>Я понимаю, что ≠ — это математический знак. Но весь мир спокойно использует != или аналоги, потому что без приседаний набрать его нельзя. То же относится к подавляющему большинству других знаков.
В принципе, ничто не мешает найти компромисс между любителями юникода и аски-наци. Например пусть компилятор считает ≠ и != равнозначными (подобная фича есть в xetex), а в ide будет опция отображать != как ≠ (подобная фича есть в емакс-моде для схемы quack — он заменяет lambda на λ).

И то только потому что в МакОСи это достаточно легко делается

И то, я помню буквально две-три комбинации клавиш

А все остальное....

M>>Я понимаю, что ≠ — это математический знак. Но весь мир спокойно использует != или аналоги, потому что без приседаний набрать его нельзя. То же относится к подавляющему большинству других знаков.
MC>В принципе, ничто не мешает найти компромисс между любителями юникода и аски-наци. Например пусть компилятор считает ≠ и != равнозначными (подобная фича есть в xetex), а в ide будет опция отображать != как ≠ (подобная фича есть в емакс-моде для схемы quack — он заменяет lambda на λ).

Это было бы неплохим компромиссом.

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

M>>>Как это относится к контексту про непечатаемые и не отображаемые символы? Правильно, никак.
B>>Прочитал твои замечания. Такое ощущуение что ты прикалываешься

M>Прикалываюсь с чего? Я, как программист, не понимаю, что может заставить меня постоянно прыгать по всей клавиатуре и/или использовать мышку для знаков, которых нет на клавиатуре и для написания которых требуются комбинации через Alt, Alt Gr или character map.

M>Я понимаю, что ≠ — это математический знак. Но весь мир спокойно использует != или аналоги, потому что без приседаний набрать его нельзя. То же относится к подавляющему большинству других знаков.

M>Другие замечания — вроде замечания про запятые — это не прикол, а реальный вопрос, на который внятного ответа так и не получено. Ну и т.п.
Про запятые ответил. Насчет знаков и клавиатур просто напомню, что и то и другое придумали люди. И я не вижу почему нельзя придумать и сделать другую клавиатуру. Это в крайнем случае. Не зря напомнил про клавиатуру Лебедева. Там клавиши меняют изображения. Ну, или еще какие варианты. Главное что они есть. И я читаю что появляется и необходимость. Ныне существующая клавиаткра содрана с печатных машинок. Кодировка кстати, тоже..

M>>>>Как это относится к контексту про непечатаемые и не отображаемые символы? Правильно, никак.
B>>>Прочитал твои замечания. Такое ощущуение что ты прикалываешься

M>>Прикалываюсь с чего? Я, как программист, не понимаю, что может заставить меня постоянно прыгать по всей клавиатуре и/или использовать мышку для знаков, которых нет на клавиатуре и для написания которых требуются комбинации через Alt, Alt Gr или character map.

M>>Я понимаю, что ≠ — это математический знак. Но весь мир спокойно использует != или аналоги, потому что без приседаний набрать его нельзя. То же относится к подавляющему большинству других знаков.

M>>Другие замечания — вроде замечания про запятые — это не прикол, а реальный вопрос, на который внятного ответа так и не получено. Ну и т.п.
B>Про запятые ответил.

Нат тот ответ я тоже уже ответил

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

Раскладок клавиатур — сотни, если не десятки сотен. Не стоит думать, что можно ВНЕЗАПНО придумать новую раскладку и все ей вдруг начнут пользоваться.

B>Это в крайнем случае. Не зря напомнил про клавиатуру Лебедева. Там клавиши меняют изображения.

Да, но там всего 104/106 клавиш. Повторю в сотый раз: если для набора текста программы надо несколько раз переключаться между режимами клавиатуры, никто таким языком программирования не будет пользоваться.

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

Не появляется.

B>Ныне существующая клавиаткра содрана с печатных машинок.

И это — реальность. И над-/подстрочные символы, и математические символы и даже «елочки» на ней набирать не просто неудобно, а ужасно неудобно (за редчайшими исключениями). Если хочется, чтобы «Ладой» пользовались, надо или сначала во всем мире сменить клавиатуры, или принять реальность, как данное и перестать придумывать, как усложнить разработчикам жизнь.

B>Кодировка кстати, тоже..

Это бессмысленное утверждение. Кодировка не может быть содрана с печатных машинок.

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

M>И это — реальность. И над-/подстрочные символы, и математические символы и даже «елочки» на ней набирать не просто неудобно, а ужасно неудобно (за редчайшими исключениями). Если хочется, чтобы «Ладой» пользовались, надо или сначала во всем мире сменить клавиатуры, или принять реальность, как данное и перестать придумывать, как усложнить разработчикам жизнь.
Что сначала курица или яйцо? Таки сначала спрос, потом предложение.. Никак не наоборот.

B>>Кодировка кстати, тоже..

M>Это бессмысленное утверждение. Кодировка не может быть содрана с печатных машинок.
А код возврат каретки откуда? А я еще помню печатные машинки переделаные под принтера. Вот и кодировку под это "железо" конструировали.

M>>И это — реальность. И над-/подстрочные символы, и математические символы и даже «елочки» на ней набирать не просто неудобно, а ужасно неудобно (за редчайшими исключениями). Если хочется, чтобы «Ладой» пользовались, надо или сначала во всем мире сменить клавиатуры, или принять реальность, как данное и перестать придумывать, как усложнить разработчикам жизнь.
B>Что сначала курица или яйцо? Таки сначала спрос, потом предложение.. Никак не наоборот.

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

B>>>Кодировка кстати, тоже..

M>>Это бессмысленное утверждение. Кодировка не может быть содрана с печатных машинок.
B>А код возврат каретки откуда? А я еще помню печатные машинки переделаные под принтера. Вот и кодировку под это "железо" конструировали.

БОльшего маразма я не слышал. Какой, к черту, код возврата каретки на печатной машинке

Кодировка вообще не имеет никакого отгношния к печатной машинке. Кодировка — это способ представления определенных символов. Хочу увидеть печтаную машинку, которой соответствует UTF-8

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

B>>>>Кодировка кстати, тоже..

M>>>Это бессмысленное утверждение. Кодировка не может быть содрана с печатных машинок.
B>>А код возврат каретки откуда? А я еще помню печатные машинки переделаные под принтера. Вот и кодировку под это "железо" конструировали.

M>БОльшего маразма я не слышал. Какой, к черту, код возврата каретки на печатной машинке

Дим, тыб чтоли вики посмотрел хотяб, но, безусловно, использовать для грамматики языка связь ASCII с пишущей машинкой довольно странное занятие...

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

M>Я понимаю, что ≠ — это математический знак. Но весь мир спокойно использует != или аналоги, потому что без приседаний набрать его нельзя. То же относится к подавляющему большинству других знаков.

Вопрос не только в написании. Текст программы нужно где-то хранить, и часто куда-то передавать, или обубликовывать(и автор уже с этим столкнулся, попытавшись опубликовать текст здесь, хотя языка-то еще и не существует). Я сам лично за юникод, но поддерживается он пока не везде. В реальной жизни использование нестандартных знаков создаст очень много проблем на пустом месте. Вобщем, соглашусь, что эта идея — полный бред.

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

MC>Здравствуйте, Mamut, Вы писали:
M>>Прикалываюсь с чего? Я, как программист, не понимаю, что может заставить меня постоянно прыгать по всей клавиатуре и/или использовать мышку для знаков, которых нет на клавиатуре и для написания которых требуются комбинации через Alt, Alt Gr или character map.
MC>Не, ну есть же люди, которые, например, используют типографскую раскладку — и везде ставят елочки, многоточия, длинные тире и т.п.

И это правильно, если текст предназначен для чтения людьми. Обычно в этом случае используется не plain text, а что-то из языков разметки, который позволяеь задать в том числе и кодировку. Для текста программы это бесмысленно.

M>>Я понимаю, что ≠ — это математический знак. Но весь мир спокойно использует != или аналоги, потому что без приседаний набрать его нельзя. То же относится к подавляющему большинству других знаков.
MC>В принципе, ничто не мешает найти компромисс между любителями юникода и аски-наци. Например пусть компилятор считает ≠ и != равнозначными (подобная фича есть в xetex), а в ide будет опция отображать != как ≠ (подобная фича есть в емакс-моде для схемы quack — он заменяет lambda на λ).

Можно еще много костылей нагородить, но зачем?

Здравствуйте, Eugeny__, Вы писали:
E__>И это правильно, если текст предназначен для чтения людьми. Обычно в этом случае используется не plain text, а что-то из языков разметки, который позволяеь задать в том числе и кодировку. Для текста программы это бесмысленно.
Я не совсем то имел в виду. Я про то, когда в юникодном плейн тексте вместо ряда аски-символов (кавычек, тире и т.п.) используются их юникодные аналоги которые мы привыкли видеть в "типографском" тексте. Чтобы так писать, юзер использует специальную клавиатурную раскладку.

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

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

MC>>Здравствуйте, Mamut, Вы писали:
M>>>Прикалываюсь с чего? Я, как программист, не понимаю, что может заставить меня постоянно прыгать по всей клавиатуре и/или использовать мышку для знаков, которых нет на клавиатуре и для написания которых требуются комбинации через Alt, Alt Gr или character map.
MC>>Не, ну есть же люди, которые, например, используют типографскую раскладку — и везде ставят елочки, многоточия, длинные тире и т.п.

E__>И это правильно, если текст предназначен для чтения людьми. Обычно в этом случае используется не plain text, а что-то из языков разметки, который позволяеь задать в том числе и кодировку. Для текста программы это бесмысленно.

На самом деле очень большое число проблем с кодом возникает из-за того, что программисты не учитывают того, про текст программы должен быть в первую очередь предназначен для чтения людьми. Ведь компилятору глубоко фиолетово будет переменная называться price, PRiCe, myMEGA_BOTVA или g789_tyRdfgmls, но вот для людей, которым надо будет разбираться с кодом, это совсем нетак.

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

MC>>>Здравствуйте, Mamut, Вы писали:
M>>>>Прикалываюсь с чего? Я, как программист, не понимаю, что может заставить меня постоянно прыгать по всей клавиатуре и/или использовать мышку для знаков, которых нет на клавиатуре и для написания которых требуются комбинации через Alt, Alt Gr или character map.
MC>>>Не, ну есть же люди, которые, например, используют типографскую раскладку — и везде ставят елочки, многоточия, длинные тире и т.п.

E__>>И это правильно, если текст предназначен для чтения людьми. Обычно в этом случае используется не plain text, а что-то из языков разметки, который позволяеь задать в том числе и кодировку. Для текста программы это бесмысленно.

К>На самом деле очень большое число проблем с кодом возникает из-за того, что программисты не учитывают того, про текст программы должен быть в первую очередь предназначен для чтения людьми. Ведь компилятору глубоко фиолетово будет переменная называться price, PRiCe, myMEGA_BOTVA или g789_tyRdfgmls, но вот для людей, которым надо будет разбираться с кодом, это совсем нетак.

Я не про то. Просто, ИМХО, читабельность кода от ввода не аски символов не улучшится особо. Зато проблем можно отхватить выше крыши. Пока еще далеко не везде используется юникод(хотя я двумя руками за форсирование этого процесса), это принесет ненужные костыли на ровном месте.

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

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

MC>>>>Здравствуйте, Mamut, Вы писали:
M>>>>>Прикалываюсь с чего? Я, как программист, не понимаю, что может заставить меня постоянно прыгать по всей клавиатуре и/или использовать мышку для знаков, которых нет на клавиатуре и для написания которых требуются комбинации через Alt, Alt Gr или character map.
MC>>>>Не, ну есть же люди, которые, например, используют типографскую раскладку — и везде ставят елочки, многоточия, длинные тире и т.п.

E__>>>И это правильно, если текст предназначен для чтения людьми. Обычно в этом случае используется не plain text, а что-то из языков разметки, который позволяеь задать в том числе и кодировку. Для текста программы это бесмысленно.

К>>На самом деле очень большое число проблем с кодом возникает из-за того, что программисты не учитывают того, про текст программы должен быть в первую очередь предназначен для чтения людьми. Ведь компилятору глубоко фиолетово будет переменная называться price, PRiCe, myMEGA_BOTVA или g789_tyRdfgmls, но вот для людей, которым надо будет разбираться с кодом, это совсем нетак.

E__>Я не про то. Просто, ИМХО, читабельность кода от ввода не аски символов не улучшится особо. Зато проблем можно отхватить выше крыши. Пока еще далеко не везде используется юникод(хотя я двумя руками за форсирование этого процесса), это принесет ненужные костыли на ровном месте.

С этим-то согласен, просто у тебя противопоставление получилось не совсем корректное, код оно тоже предназначен для чтения, но, вместе с тем, предназначен для модификации, а извращённые символы тут в основном мешают, о чём, собственно мамут тут уже не раз написал.

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

E__>>Я не про то. Просто, ИМХО, читабельность кода от ввода не аски символов не улучшится особо. Зато проблем можно отхватить выше крыши. Пока еще далеко не везде используется юникод(хотя я двумя руками за форсирование этого процесса), это принесет ненужные костыли на ровном месте.

К>С этим-то согласен, просто у тебя противопоставление получилось не совсем корректное, код оно тоже предназначен для чтения, но, вместе с тем, предназначен для модификации, а извращённые символы тут в основном мешают, о чём, собственно мамут тут уже не раз написал.

Просто стандарт для хранения кода по-умолчанию — текст(и на это многое завязано). Для какой-нибудь публикации для прочтения людьми — доки, пдф и прочее. Так вот последние обычно хранятся как файлы, т.е. бинари, и туда вставляй хоть картинки, хоть хитросимволы — никто не пострадает. Я в этом смысле имел ввиду. Хранение кода в .doc — кошмарный сон, а для текста ничего вполне.

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

M>>>Описанная схема напоминает механимз слоты/сигналы, что есть в Qt, но с дополнительными плюшками и сахаром. Согласен, похожая схема была бы интересна, как дополнение к существующим инструментам.
B>>Спасибо! Сегодня какой-то удачный день. За пол года сегодня ты второй кто эту фишку понял. До этого было сплошное фи. Если так и дальше пойдет, то еще через полгода появятся въехавшие в гуппирование и в реализацию. Это уже будет перелом. Пока въехавших нет.

M>Ну если ты не можешь внятно объяснить, что это такое, то

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

Это действительно что-то вроде пролога, с прикрученной императивностью. То бишь, декларативно задаются императивные блоки, выполняемые в некие моменты вычислений... Скажу честно, интересный ход мыслей... Сразу вспоминается задача моделирования аппаратуры, которая достаточно сложна на императивных языках, но была бы проще на порядки на Ладе. Просто у автора трудности с терминологией (опыт VB оказался скорее вреден), поэтому не может объяснить тривиальных вещей. Для простоты понимания держите в голове, что вычисления производятся интерпретатором, причем, интерпретатор — это не аналог некоей современной VM, работающей по байт-коду, а "внешний вычислитель", типа допиленного интерпретатора Пролога. Соответственно, понятие потока исполнения тоже отличается от оного в императивных программах. Поток исполнения блока юзверьского кода тут вызывается из некоей точки вычисления интерпретатора. То бишь, физический поток исполнения, похоже, всего один, но можно писать многопоточные с логической т.з. программы.

Интересно было глянуть на библиотеку ввода-вывода для языка. Сдается мне, она может быть только асинхронной.

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

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

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

B>Если вы комментируете мою самокритику, то рекомендую вам быть таким же самокритичным.

Странный ты. AVK высказал разумную мысль. В отличии от тебя язык он свой не предлагал, и твой не критиковал. Что же ему быть самокритичным то?

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

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

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

VD>Значит тебе твой чудо-язык придется делать одному до релиза, так как пока ты не объяснишь все другим, эти другие тебе помогать не будут.
Я не настолько наивен, что бы ожидать помощи. Один и делаю. А насчет понимания, я все написал. Там думать надо. Это необычный подход. И опыт прежних языков угадывается, но сильно отличается по внутреннему содержанию. Пока я не видел ни одного, кто бы внимательно и вдумчиво прочитал хотя бы три раздела.

B>>Если вы комментируете мою самокритику, то рекомендую вам быть таким же самокритичным.

VD>Странный ты. AVK высказал разумную мысль. В отличии от тебя язык он свой не предлагал, и твой не критиковал. Что же ему быть самокритичным то?
КАКУЮ МЫСЛЬ? Я внимательно слежу и благодарен именно за мысль. Сформулируй, и я немедленно извинюсь.

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

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

Да, да. Это как в том анекдоте...
— Милый. Будь осторожен. По телевизору передали что какой-то идиот едет по встрчке.
— Один? Да их тут тысячи!

B>КАКУЮ МЫСЛЬ? Я внимательно слежу и благодарен именно за мысль. Сформулируй, и я немедленно извинюсь.

Очень простую:

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

В прочем всегда есть шанс, что тот кого не понимают окружающие — это гений сильно опередивший время. В одном случае на миллиард так и случается.

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

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

VD>Очень простую:
VD>

VD>Поскольку объяснить ты не в состоянии уже долгое время, то понятность внутри твоей головы тебе только кажется.

VD>В прочем всегда есть шанс, что тот кого не понимают окружающие — это гений сильно опередивший время. В одном случае на миллиард так и случается.
Думаю вы сильно преувеличиваете. Куда чаще встречается просто лень. На самом деле думать это сложное занятие.

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

VD>>В прочем всегда есть шанс, что тот кого не понимают окружающие — это гений сильно опередивший время. В одном случае на миллиард так и случается.
B>Думаю вы сильно преувеличиваете. Куда чаще встречается просто лень. На самом деле думать это сложное занятие.

И это говорит человек, который поленился в документации не только не указать каким образом LADA облегчит жизнь по сравнению с, но даже не узнать что NOD пишется как GCD. И это говорит человек который до сих пор поленился разобраться с github/googlecode/sf. HIBT?

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

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

VD>>>В прочем всегда есть шанс, что тот кого не понимают окружающие — это гений сильно опередивший время. В одном случае на миллиард так и случается.
B>>Думаю вы сильно преувеличиваете. Куда чаще встречается просто лень. На самом деле думать это сложное занятие.

M>И это говорит человек, который поленился в документации не только не указать каким образом LADA облегчит жизнь по сравнению с, но даже не узнать что NOD пишется как GCD. И это говорит человек который до сих пор поленился разобраться с github/googlecode/sf. HIBT?
Чем то напомнило анекдот про Вовочку, когда он увидел как отец с мамой сексом занимаются.
-И эти люди запрещают мне в носу ковыряться!

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

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

Здравствуйте, batu, Вы писали:
B>которые привели к созданиям этих объектов. Ну, на заре компьютерной техники на такие нюансы не обращали внимания. Как и на то, что нет английской буквы "а" и русской буквы "а". Есть знак "а" который в разных языках ассоциируется в разные алфавиты. В тексте никогда не возникает вопрос "это русская буква Р?". Этот вопрос имеет смысл только в устной речи, когда необходимо установить обратную ассоциацию из алфавита в знак.
Это заблуждение. Русская А и английская A — совершенно разные знаки. Это видно, к примеру, в хороших шрифтах — начертания знаков отличаются. Точно так же и все внешне похожие друг на друга кириллические и латинские символы являются на деле разными. У них разное происхождение, разная фонетика, разные традиции начертания.
Я понимаю, это трудно понять, и разница кажется неочевидной — особенно людям, воспитанным на шрифтах, полученных тупым заимствованием латиницы (в особо вопиющих случаях букву Я могли получать разворотом R). Посмотрите в таком случае на какие-нибудь арабские или другие языки с принципиально другими алфавитами. Практически в каждом алфавите земли есть знак, похожий на O. Считать его из-за этого тем же знаком никто не станет.
Далее: как раз в устной речи никакой проблемы идентификации знаков не стоит — там вообще нет ни знаков, ни алфавитов. Есть фонемы. Только в письменной речи могут возникать проблемы интерпретации — puma это рита или пума.

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

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

S>Я понимаю, это трудно понять, и разница кажется неочевидной — особенно людям, воспитанным на шрифтах, полученных тупым заимствованием латиницы (в особо вопиющих случаях букву Я могли получать разворотом R). Посмотрите в таком случае на какие-нибудь арабские или другие языки с принципиально другими алфавитами. Практически в каждом алфавите земли есть знак, похожий на O. Считать его из-за этого тем же знаком никто не станет.

Разница в воспитании не причем. Повторюсь. Ассоциация знака на фонемы и на алфавит в разных языках однозначно разная. Что ж тут возражать. А вот считать можно и одним и не одним знаком. Дело вкуса.

S>Далее: как раз в устной речи никакой проблемы идентификации знаков не стоит — там вообще нет ни знаков, ни алфавитов. Есть фонемы. Только в письменной речи могут возникать проблемы интерпретации — puma это рита или пума.
Прекрасный пример демонстрирующий что нет знаков русских и английских. Есть разная ассоциация этих знаков в разных языках.
Я говорил о другом. Если вы захотите собеседнику сказать какой первый знак у вас в примере, вы вынуждены будете произнести либо русское "р", либо английское "п".
С уважением!

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

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

XC>>>Это какая-то попытка запихать инструкции (операторы языка) в парадигму ООП?
B>>Да. Только почему "запихать"? Так оно и есть..Объект-инструкция..
B>> А почему бы и нет?
Раз 5 перечитал. Не уловил логику. Извини.
S>А, собственно, зачем? У инструкции никакого поведения нет. Поведение есть у компилятора, который на основе набора инструкций должен породить программу для целевой машины.
И что имеется ввиду под поведением?
Компилятор работает на основе синтаксиса. О каком наборе инструкций идет речь?
А если целевая машина принимает на входе объекты? Логично тогда ожидать что компилятор должен создать объекты? Не надо зацикливаться на том, что целевая машина это воспринимает только коды процессора.
И, наконец, не понял что именно следует из вашего замечания.

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

S>Задача "объекта-инструкции" сводится к тому, чтобы хранить данные, необходимые для компилятора. И это мало кому интересно — потому, что код компилируется один раз, а исполняется — миллионы раз.
S>Ну, то есть устройство компилятора само по себе конечно же интересное дело — вон как народ по соседству бурлит насчёт всех этих GLR парсеров и прочего. Но проектировать из этого язык... Язык нужен для человека, а не для компилятора.
Спорное утверждение.
К тому же в компиляции процесс лексического и синтаксического разбора — далеко не самая интересная задача. Дальше-то вы что будете делать? Каким образом вы собираетесь порождать целевой код?
По-моему ответил.
Или это будет чистая интерпретация?

И интерпретация и компиляция.
Интерпретация применяется как текстовый процессор. Те же операторы, работающие с теми же объектами, если данные оператора имеют значения на этапе редактирования, то почему бы его не выполнить?
Например, если в тексте 7+5 почему бы не выполнить оператор сложения? Кроме того у меня предусмотрен сценарий в котором можно (а иногда и нужно) определять как структуры данных, так и сами данные. И в тексте программы или текстового документа (в моем редакторе нет разницы) оператор Var определяет типа статические значения, которые можно использовать в качестве данных, тогда следующий оператор выполнится как интерпретатор.

Var Boolean Debug=True
...
..
If F then {Print "a"}
...

А затем поступит в компилятор.. и т.д..
Единственная разница, что у меня все операторы могут выполняться как интерпретаторы.

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

B>И интерпретация и компиляция.
B>Интерпретация применяется как текстовый процессор.

Неясно. Текстовыми процессорами у нас называли то ли MultiEdit, то ли препроцессор вы имеете ввиду?

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

B>Например, если в тексте 7+5 почему бы не выполнить оператор сложения?
7+5 традиционно выполняет компилятор через оптимизацию. Собственно 7+5 выполнить очень легко при обработке AST выражения. На пальцах это очень просто. Вопросы возникают если X+Y могут быть выполнены на этапе компиляции, но это не int. Вы к этому готовы?

B>Кроме того у меня предусмотрен сценарий в котором можно (а иногда и нужно) определять как структуры данных, так и сами данные. И в тексте программы или текстового документа (в моем редакторе нет разницы) оператор Var определяет типа статические значения, которые можно использовать в качестве данных, тогда следующий оператор выполнится как интерпретатор.
Непонятно (и ниже тоже). Вы взялись за не простую вещь, — будьте строги прежде всего к себе в формулировках. Оператор он оператор. Оператор не интерпретатор, так же как чайник не красное. Ошибки в формулировках как правило говорят или о неумении выразить свои мысли, или о каше в голове, или ничего не говорят.

В любом случае какие бы умные мысли вы бы не выражали — если вы их выражаете неправильно — это минус только вам. Так что этот параграф попал в разряд магии.

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

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

B>>И интерпретация и компиляция.
B>>Интерпретация применяется как текстовый процессор.
F>

Неясно. Текстовыми процессорами у нас называли то ли MultiEdit, то ли препроцессор вы имеете ввиду?
Препроцессор.

B>>Те же операторы, работающие с теми же объектами, если данные оператора имеют значения на этапе редактирования, то почему бы его не выполнить?
F> Почему бы и нет, а надо? А когда? А как?
Иногда надо. Например включить в текст документа операторы отладки, или в тексте документа открыть/скрыть данные доступные для одного сотрудника и закрытые для другого. Или сформировать бланк документа изменяя какие то данные, типа нового заказчика.

B>>Например, если в тексте 7+5 почему бы не выполнить оператор сложения?
F> 7+5 традиционно выполняет компилятор через оптимизацию. Собственно 7+5 выполнить очень легко при обработке AST выражения. На пальцах это очень просто. Вопросы возникают если X+Y могут быть выполнены на этапе компиляции, но это не int. Вы к этому готовы?
Если там есть значения и нет проблем с типами почему бы и нет.

B>>Кроме того у меня предусмотрен сценарий в котором можно (а иногда и нужно) определять как структуры данных, так и сами данные. И в тексте программы или текстового документа (в моем редакторе нет разницы) оператор Var определяет типа статические значения, которые можно использовать в качестве данных, тогда следующий оператор выполнится как интерпретатор.
F> Непонятно (и ниже тоже). Вы взялись за не простую вещь, — будьте строги прежде всего к себе в формулировках. Оператор он оператор. Оператор не интерпретатор, так же как чайник не красное. Ошибки в формулировках как правило говорят или о неумении выразить свои мысли, или о каше в голове, или ничего не говорят.

В любом случае какие бы умные мысли вы бы не выражали — если вы их выражаете неправильно — это минус только вам. Так что этот параграф попал в разряд магии.
Имелось ввиду оператор выполнится в режиме интерпретатора. Согласен что не точность. Но не каша.

Спасибо за замечание. Про сценарий не пишу подробно потому что там много надо писать. Считаю в таком виде пока достаточно. Вопрос же был не о нем.

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

B>И что имеется ввиду под поведением?
Под поведением имеется в виду то, которое из стандартного определения объекта: объект суть сущность, обладающая идентичностью, состоянием, и поведением.
То есть — способность объекта реагировать на посылаемые ему сообщения, возможно изменяя своё состояние.
Пока понятно?

B>Компилятор работает на основе синтаксиса. О каком наборе инструкций идет речь?
В общем-то, о любом — и о наборе входных инструкций (или любых других элементов языка), и о наборе выходных инструкций.

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

B> При этом эта программа зачастую достаточно сильно отличается по структуре от структуры исходной программы.
B>Ну, отличается. Это хорошо или плохо?
Это, в общем случае, хорошо. Потому что позволяет сделать скомпилированную программу эффективнее исходной.
B>По моему плохо. Я бы предпочел что б не отличалось. И это тоже можно сделать, если целевая машина будет моделировать машину Тьюринга с дополнительной адресной лентой, а не исполнять инструкции подряд.
А я бы предпочёл, чтобы скорость света была на пару десятков порядков выше. Шутка.
Поймите, я говорю о том, что если в исходном языке есть конструкция "for i=0 to 10 {...}", то нет никакой гарантии в том, что в выходной программе останется хоть что-то, напоминающее по своей семантике for. В самом простом случае компилятор может развернуть цикл, в сложном — вообще упростить всё вычисление до константы. А вы наивно предлагаете создавать объекты для всего, встреченного компилятором. Зачем нам i в целевой программе?

ИB>спользуя конвейерную технологию это практически никак не повлияет на скорость зато позволит создать прямую связь между объектами создаными компилятором и текстом программы, что в свою очередь значительно упростит документирование, сопровождение и создание отладочных средств.
Можно, я не буду обсуждать скорость машины Тьюринга? Давайте поговорим про документирование и сопровождение. Вот, скажем, вы видели реальную программу? Ну там, hello world на C#?
Там связь между "объектами, созданными компилятором" и текстом программы весьма непрямая. Давайте попробуем раскрыть тему и пояснить мне, где здесь сложности документирования и сопровождения? Очень редкий C#-программист может сопоставить текст hello world и инструкции x86, в которые он превращается после работы компилятора и jit. Но никто и никогда не занимается документированием программы в терминах "целевого кода".

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

B>По-моему ответил.
По-моему нет.

B>И интерпретация и компиляция.
B>Интерпретация применяется как текстовый процессор. Те же операторы, работающие с теми же объектами, если данные оператора имеют значения на этапе редактирования, то почему бы его не выполнить?
Текстовый процессор бесконечно далёк от интерпретации. Зачем вы его упоминаете? Вот, например, я пользуюсь текстовым процессором Microsoft Word версии 14. Он, конечно, занимается интерпретацией вводимых в него текстов документов — ну, скажем, угадывает, что после точки должно начаться новое предложение и предлагает мне начать дальнейший текст с заглавной буквы. Но это совсем не то, чего мы ожидаем от среды программирования.

B>Например, если в тексте 7+5 почему бы не выполнить оператор сложения? Кроме того у меня предусмотрен сценарий в котором можно (а иногда и нужно) определять как структуры данных, так и сами данные. И в тексте программы или текстового документа (в моем редакторе нет разницы) оператор Var определяет типа статические значения, которые можно использовать в качестве данных, тогда следующий оператор выполнится как интерпретатор.
Не очень понятно, что значит "выполнится как интерпретатор"? У меня закрадывается подозрение, что вы используете стандартные термины каким-то очень нешаблонным способом. В частности, здесь субъект и объект явно перепутаны местами.
Обычно интерпретатор занимается выполнением операторов.
Ну вот, к примеру, интерпретатор читает предложение LET Z = X+Y. Он сразу интерпретирует его как инструкцию завести в виртуальной машине переменную с именем Z и положить в неё результат выполнения оператора + над переменными X и Y. И немедленно выполняет.
Но сам оператор + здесь ничего не делает. Это всего лишь идентификатор, который помогает интерпретатору понять, что нужно делать.

B>А затем поступит в компилятор.. и т.д..
Что именно затем поступит в компилятор? И что именно делает у вас компилятор?
B>Единственная разница, что у меня все операторы могут выполняться как интерпретаторы.
Разница между чем и чем, простите?

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

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

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

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

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

B>> При этом эта программа зачастую достаточно сильно отличается по структуре от структуры исходной программы.
B>>Ну, отличается. Это хорошо или плохо?
S>Это, в общем случае, хорошо. Потому что позволяет сделать скомпилированную программу эффективнее исходной.
B>>По моему плохо. Я бы предпочел что б не отличалось. И это тоже можно сделать, если целевая машина будет моделировать машину Тьюринга с дополнительной адресной лентой, а не исполнять инструкции подряд.
S>А я бы предпочёл, чтобы скорость света была на пару десятков порядков выше. Шутка.
S>Поймите, я говорю о том, что если в исходном языке есть конструкция "for i=0 to 10 {...}", то нет никакой гарантии в том, что в выходной программе останется хоть что-то, напоминающее по своей семантике for. В самом простом случае компилятор может развернуть цикл, в сложном — вообще упростить всё вычисление до константы. А вы наивно предлагаете создавать объекты для всего, встреченного компилятором.
Ну, и я так понимаю. Видимо одинаковые книжки читали. Могу еще пример преобразования выражений привести. Вот только ироническое "наивно" не принимаю. Да предлагаю, и отнюдь не наивно. Хотя спорно.
Зачем нам i в целевой программе?
А для формирования сообщения в случае необходимости в терминах исходника. И для сопровождения, для документирования.

ИB>>спользуя конвейерную технологию это практически никак не повлияет на скорость зато позволит создать прямую связь между объектами создаными компилятором и текстом программы, что в свою очередь значительно упростит документирование, сопровождение и создание отладочных средств.
S>Можно, я не буду обсуждать скорость машины Тьюринга? Давайте поговорим про документирование и сопровождение. Вот, скажем, вы видели реальную программу? Ну там, hello world на C#?
S>Там связь между "объектами, созданными компилятором" и текстом программы весьма непрямая. Давайте попробуем раскрыть тему и пояснить мне, где здесь сложности документирования и сопровождения? Очень редкий C#-программист может сопоставить текст hello world и инструкции x86, в которые он превращается после работы компилятора и jit. Но никто и никогда не занимается документированием программы в терминах "целевого кода".
И напрасно не занимались. Только не в терминах целевого кода, а в терминах исходника.

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

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

B>>И интерпретация и компиляция.
B>>Интерпретация применяется как текстовый процессор. Те же операторы, работающие с теми же объектами, если данные оператора имеют значения на этапе редактирования, то почему бы его не выполнить?
S>Текстовый процессор бесконечно далёк от интерпретации. Зачем вы его упоминаете? Вот, например, я пользуюсь текстовым процессором Microsoft Word версии 14. Он, конечно, занимается интерпретацией вводимых в него текстов документов — ну, скажем, угадывает, что после точки должно начаться новое предложение и предлагает мне начать дальнейший текст с заглавной буквы. Но это совсем не то, чего мы ожидаем от среды программирования.

B>>Например, если в тексте 7+5 почему бы не выполнить оператор сложения? Кроме того у меня предусмотрен сценарий в котором можно (а иногда и нужно) определять как структуры данных, так и сами данные. И в тексте программы или текстового документа (в моем редакторе нет разницы) оператор Var определяет типа статические значения, которые можно использовать в качестве данных, тогда следующий оператор выполнится как интерпретатор.
S>Не очень понятно, что значит "выполнится как интерпретатор"? У меня закрадывается подозрение, что вы используете стандартные термины каким-то очень нешаблонным способом. В частности, здесь субъект и объект явно перепутаны местами.
S>Обычно интерпретатор занимается выполнением операторов.
S>Ну вот, к примеру, интерпретатор читает предложение LET Z = X+Y. Он сразу интерпретирует его как инструкцию завести в виртуальной машине переменную с именем Z и положить в неё результат выполнения оператора + над переменными X и Y. И немедленно выполняет.
S>Но сам оператор + здесь ничего не делает. Это всего лишь идентификатор, который помогает интерпретатору понять, что нужно делать.

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

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

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

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

B>И что мешает набор инструкций считать объектами?
Отсутствие у них состояния и поведения.
B>А зачем все уничтожать? Кое-что пусть и остается. Как документ.
Документ не имеет никакого отношения к объектам-инструкциям. Рассмотрите документирование кода на примере javadoc. Вы знакомы с этим явлением?

B>Не нужно. Только если их нет где-то, не означает что их нет нигде. У меня есть.
А у вас уже есть целевая машина?

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

B>Зачем нам i в целевой программе?
B>А для формирования сообщения в случае необходимости в терминах исходника. И для сопровождения, для документирования.
Непонятно. Для сопровождения и документирования достаточно сопровождать и документировать исходник. См. опять же javadoc и XML comments в C#.
Формирование соощения в терминах исходника — крайне редкая необходимость. Кроме того, потребности по формированию этого сообщения совсем другие, чем потребности исполняющей среды по реализации семантики вашей программы.
Приведу такой пример из реального мира: вот у нас бывают исключения в .Net. В исключении для удобста отладки и формирования сообщений приклеен стек вызовов. Сам по себе стек вполне себе объектно-ориентирован (хотя объекты, из которых он состоит, immutable, и общему определению объекта не очень удовлетворяют). Но это не означает, что к исключению приклеивают тот самый стек, который используется внутри исполняющей машины. Никто не создаёт объект StackFrame при каждом вызове подпрограммы. StackTrace собирается из доступной информации только в момент выброса исключения. А для исполнения используется обычный стек x86.
Это сделано не потому, что разработчики CLR не смогли применить передовые концепции, а потому, что они были бы слишком дорогими — производительность была бы ниже всякой критики.

S>>Там связь между "объектами, созданными компилятором" и текстом программы весьма непрямая. Давайте попробуем раскрыть тему и пояснить мне, где здесь сложности документирования и сопровождения? Очень редкий C#-программист может сопоставить текст hello world и инструкции x86, в которые он превращается после работы компилятора и jit. Но никто и никогда не занимается документированием программы в терминах "целевого кода".
B>И напрасно не занимались. Только не в терминах целевого кода, а в терминах исходника.
Я уже писал про javadoc и XML comments?

S>>Ну попробуйте оспорить, раз оно спорное. Вы вообще роль языков программирования в современной индустрии ПО как себе представляете?

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

Секрет успеха языка — в том, чтобы человеку было удобно выражать мощные концепции.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

B>3. Синтаксический анализ создает из последовательности объектов-лексем и объектов-знаков новые объекты! Так как синтаксис у меня простой сначала имя класса ,а затем имя создаваемого объекта (далее в скобках идет присвоение значений свойств объекту и определение вложеных объектов) то выглядит это примерно так.

B>

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

B>Из первой строки синтаксический анализатор создаст форму с вложеной меткой и текстом "Конечно".
B>Вторая строка создаст объект-инструкцию класса For, с вложенными операторами J+=1 Z=X*Y
Это всё понятно. Непонятно, зачем вы создаёте эту объект-инструкцию. Точнее, зачем вы на этом концентрируетесь.
В обычном жизненном цикле программы все эти объекты эфемерны — они существуют во время работы компилятора. Как только компилятор сгенерировал целевой код, никакие объекты-инструкции не нужны.

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

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

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

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

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

B>>3. Синтаксический анализ создает из последовательности объектов-лексем и объектов-знаков новые объекты! Так как синтаксис у меня простой сначала имя класса ,а затем имя создаваемого объекта (далее в скобках идет присвоение значений свойств объекту и определение вложеных объектов) то выглядит это примерно так.

B>>

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

B>>Из первой строки синтаксический анализатор создаст форму с вложеной меткой и текстом "Конечно".
B>>Вторая строка создаст объект-инструкцию класса For, с вложенными операторами J+=1 Z=X*Y
S>Это всё понятно. Непонятно, зачем вы создаёте эту объект-инструкцию. Точнее, зачем вы на этом концентрируетесь.
Для того что б был понятен подход.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

S>

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

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

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

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

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

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

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

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

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

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

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

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

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

New Event Noon
{Condition =

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

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

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

Event
{Condition =

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

B>New Event Noon
B>{Condition =

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

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

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

B>Event
B>{Condition =

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

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

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

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

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

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

For I=0 To 20 {...}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да запросто

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

Здравствуйте, 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+[номер]. У меня ничего не изменяется. Пробовал писать?
Вы про это? Тогда — да, пробовал.

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>Вы про это? Тогда — да, пробовал.

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 не существует?

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

Здравствуйте, 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 забыл.

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__>Просьба не оверквотить так жестоко. Из гостей — понятно, с кем не бывает, но уважайте собеседников.
Видимо я по другому воспитан. Считаю что лучше ответить и объясниться, чем молчать, вызывая недоумение.

Или тут мы имеем опять непонимание терминов и, как следствие, пункта 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>>

Здравствуйте, 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>>>

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

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

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

Здравствуйте, 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>Я уже пытался это объяснить несколько постингов назад, но не вижу понимания с вашей стороны. Возможно, это просто я никак не могу воспринять ваши идеи.
Будем считать что понял. Есть идеи, но они достаточно сырые.

Здравствуйте, 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/
Особенно рекомендую вторую часть.

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

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

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

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

Инструкции виртуальной машины выполняет, очевидно, виртуальная машина. И эти инструкции могут представлять из себя что угодно, хоть объекты, хоть списки Лиспа, хоть слова Форта.

Если он пишет транслятор/VM на VB, то в его распоряжении есть только объекты, так что ничего удивительного. "Я его слепила из того что было..."

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

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

А все давно уже предложено и обсуждено. В языках со строгой статической типизацией вызов несуществующего метода не компилируется. Если язык с динамической типизацией — ошибка будет в рантайме. Преимущества и того и другого подхода давно обсуждены многократно, поищи на этом сайте.

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

V>Инструкции виртуальной машины выполняет, очевидно, виртуальная машина. И эти инструкции могут представлять из себя что угодно, хоть объекты, хоть списки Лиспа, хоть слова Форта.

Выше были "инструкции, которые сами себя выполняют", учитываем твоё утверждение выше, получается виртуальная машиная является инструкцией, так? И интерпретатор форта также является его инструкцией, так?

V>Если он пишет транслятор/VM на VB, то в его распоряжении есть только объекты, так что ничего удивительного. "Я его слепила из того что было..."

Да пусть хоть пирожки, только пирожки сами себя выполнять врядли смогут, на мой взгляд, или всё-таки есть способ?

Здравствуйте, Sinclair, Вы писали:
S>Какое совпадение! Моя сестра тоже живёт в Новосибирске. Есть у нас что-то общее.
Есть.

S>Именно это я и имел в виду. Возможно, встраивание событий прямо в язык может дать какие-нибудь преимущества, но надо сначала понять, какие недостатки есть в использовании библиотеки.
Из недостатков только то, что это только одна из идей.

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

Выяснить наличие конфликта можно и сразу. Если так поставить задачу.

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

V>А все давно уже предложено и обсуждено. В языках со строгой статической типизацией вызов несуществующего метода не компилируется. Если язык с динамической типизацией — ошибка будет в рантайме. Преимущества и того и другого подхода давно обсуждены многократно, поищи на этом сайте.
А ты удачно все объяснил. Нет смысла искать.

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

V>>Инструкции виртуальной машины выполняет, очевидно, виртуальная машина. И эти инструкции могут представлять из себя что угодно, хоть объекты, хоть списки Лиспа, хоть слова Форта.

К>Выше были "инструкции, которые сами себя выполняют", учитываем твоё утверждение выше, получается виртуальная машиная является инструкцией, так? И интерпретатор форта также является его инструкцией, так?

Задача интерпретатора Форта — это запускать на исполнение "инструкции", то бишь исполняемые слова в терминологии Форта.

V>>Если он пишет транслятор/VM на VB, то в его распоряжении есть только объекты, так что ничего удивительного. "Я его слепила из того что было..."

К>Да пусть хоть пирожки, только пирожки сами себя выполнять врядли смогут, на мой взгляд, или всё-таки есть способ?

Ну да, VM запускает инструкции на выполнение. Разумеется, его "инструкции" должны как-то получать управление. А я думаю, тут все прозрачно было объяснено. Исполняемый код представляет из себя массив объектов, а не кодов. И вот поочередно этим объектам передается управление. Что тут сложного, и в чем принципиальное отличие от Форта/Лиспа?

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

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

V>>>Инструкции виртуальной машины выполняет, очевидно, виртуальная машина. И эти инструкции могут представлять из себя что угодно, хоть объекты, хоть списки Лиспа, хоть слова Форта.

К>>Выше были "инструкции, которые сами себя выполняют", учитываем твоё утверждение выше, получается виртуальная машиная является инструкцией, так? И интерпретатор форта также является его инструкцией, так?

V>Задача интерпретатора Форта — это запускать на исполнение "инструкции", то бишь исполняемые слова в терминологии Форта.

V>>>Если он пишет транслятор/VM на VB, то в его распоряжении есть только объекты, так что ничего удивительного. "Я его слепила из того что было..."

К>>Да пусть хоть пирожки, только пирожки сами себя выполнять врядли смогут, на мой взгляд, или всё-таки есть способ?

V>Ну да, VM запускает инструкции на выполнение. Разумеется, его "инструкции" должны как-то получать управление. А я думаю, тут все прозрачно было объяснено. Исполняемый код представляет из себя массив объектов, а не кодов. И вот поочередно этим объектам передается управление. Что тут сложного, и в чем принципиальное отличие от Форта/Лиспа?

Думается он думает по-естественому, а здесь пытаются сразу притянуть к архитектуре.
Убивая все то что может получится непохожее на другие языки. Так вот Лисп был придуман тогда, когда мозг математика еще не был загажен архитектурой определенного вычислительного корча. Если мыслить узко спускаясь к таким "драйверным" штукам как процессор, память, тип переменной, то выйдет еще один никому ненужный язык, потому что таких уже напридумывали и нариализовывали тысячи.

Если мыслить более широко, то любое поведенье всеравно можно замоделировать на машине тьюринга, даже такое когда все комманды "обьекты" и умеют выполнять себя самостоятельно, выполняются параллельно и процессор здесь для философского поиска вовсе неинтересен.

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

V>Ну да, VM запускает инструкции на выполнение. Разумеется, его "инструкции" должны как-то получать управление. А я думаю, тут все прозрачно было объяснено. Исполняемый код представляет из себя массив объектов, а не кодов. И вот поочередно этим объектам передается управление. Что тут сложного, и в чем принципиальное отличие от Форта/Лиспа?

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

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

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

V>>Ну да, VM запускает инструкции на выполнение. Разумеется, его "инструкции" должны как-то получать управление. А я думаю, тут все прозрачно было объяснено. Исполняемый код представляет из себя массив объектов, а не кодов. И вот поочередно этим объектам передается управление. Что тут сложного, и в чем принципиальное отличие от Форта/Лиспа?

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

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

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

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

B>Ситуация следующая. Мы выяснили что инструкции и значения не объекты. Я их объединил под общим названием потому что они формируются по общим правилам, и единому формату. Теперь возник вопрос как теперь мне все это называть? Объявляется конкурс. Жду предложений..

Можно называть (сюрприз!) "инструкции" и "значения". Чем меньше своих слов придумано — тем лучше.

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

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

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

V>>>Ну да, VM запускает инструкции на выполнение. Разумеется, его "инструкции" должны как-то получать управление. А я думаю, тут все прозрачно было объяснено. Исполняемый код представляет из себя массив объектов, а не кодов. И вот поочередно этим объектам передается управление. Что тут сложного, и в чем принципиальное отличие от Форта/Лиспа?

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

PC_>Все дело в уровнях абстракций. Машина Тьюринга ничего не знает о паралельно работающих процессах например, которые как бы "думают" что тоже сами по себе и живут в отдельном адресном пространстве ...

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

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

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

Вполне себя возьмет если этот интеграл вбить например формулу в ячейку на листе в Экселе

Эксель — это хороший пример абстракции, где ячейки тоже как-бы сами себя выполняют и пересчитывают.

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

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

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

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

PC_>Вполне себя возьмет если этот интеграл вбить например формулу в ячейку на листе в Экселе

Эксель — это хороший пример абстракции, где ячейки тоже как-бы сами себя выполняют и пересчитывают.

PC_>Хотя если Вы решили завести разговор про ассемблер и все такое то давайте выкинем например понятие итерация. И будем упорно утверждать что процессор ничего не знает о каких-то там циклах, ведь он всего лишь прыгает по меткам.

Очень показательно — придумать утверждение за оппонента и опровергать его, тем более когда оно никаким боком не относится к обсуждаемому. Такая дискуссия неинтересна, ведите её с batu.

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

B>>Ситуация следующая. Мы выяснили что инструкции и значения не объекты. Я их объединил под общим названием потому что они формируются по общим правилам, и единому формату. Теперь возник вопрос как теперь мне все это называть? Объявляется конкурс. Жду предложений..

T>Можно называть (сюрприз!) "инструкции" и "значения". Чем меньше своих слов придумано — тем лучше.
Так скажи как обозвать все вместе объекты, значения и инструкции.

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

К>Ну раз инструкции получают управление и сами делают, всё что нужно, то мне больше добавить нечего.

Откуда такая непроходимость? Вот есть язык Лисп, который я упомянул уже многократно. Ты примерно представляешь, как работает программа, написанная на этом языке? Фактически — точно так же. Программа после "проглатывания" интерпретатором представляет из себя списки списков объектов. Те объекты, которые имеют тип "функция", имеют метод вроде такого (варианты на managed-языках):

public override LispObject eval(Cons args, Cons context);

Встроенные ф-ии, т.е. реализованные разработчиком, переопределяют этот метод и что-то делают, согласно спецификации. А вот все пользовательские ф-ии представляют из себя экземпляры объекта одного и того же типа, который, при получении управления, т.е. при вызове у него eval() проходит по своему "телу" (тоже список списков) и вызывает каждый список на исполнение, то бишь первый элемент считается ф-ей, у которой вызывается eval, а оставшиеся элементы списка подаются как аргументы. Таким образом, с точки зрения модели работы Лиспа, осуществляют выполнение кода VM Лиспа именно пользовательские ф-ии, в процессе итерирования своего "тела". И в этой модели нет места "внешнему вычислителю", который присутствует в специифкациях .Net или Java VM.

Дай этим объектам-функциям из Лиспа имя "инструкция", и ты поймешь, как работает Лада.

Догадываясь о возможных вопросах — да, еще на этапе трансляции, при формировании "тел" функций, транслятор проверяет, чтобы тело ф-ии было корректным, то бишь первые элементы этих списков имели тип, вроде некоего "ObjectType.Function". Реализации на не-ОО языках используют флаги, указывающие на тип объекта, но общая схема работы примерно такая же.

В Форте тоже похожая схема. Программа состоит из адресов. Интерпретатор Форта последовательно передает управление на эти адреса путем простого вызова (ассемблерная инструкция call). Встроенные ф-ии что-то делают, и в конце идет ret, а вот пользовательские ф-ии содержат первой инструкцией call опять на тот же интерпретатор, который из стека достает адрес возврата, считая, что по этому адресу лежит тело пользовательской ф-ии, то бишь список адресов, по которым в цикле надо пройтись и сделать опять этот call над каждым адресом. Получается, что в Форте аналогично как в Лиспе: каждый код, т.е. каждая инструкция программы — это ссылка на ф-ию, а не код некоего автомата из таблицы.

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

Да ради бога. Уже разжевали и в рот положили неоднократно. Была же затравка: для абстрактной VM, инструкция — лишь абстракция. При чем тут инструкции автомата, то бишь коды, кои представляют из себя ячейки той ленты машины тьюринга?

И с чего ты взял, что вычислительный процесс непременно обязательно описать автоматной моделью, и инструкции обязаны быть кодами автомата? Особенно учитывая модные течения, вроде функционального программирования или data-flow процессоры, которое не являются аналогами тьюринг-машины, и где инструкции как раз и представляют из себя фактически обособленные объекты, т.к. содержат код операции и все необходимые данные к ней (вернее наоборот, в терминологии data-flow есть данные, а инструкции к ним идут как признак, tag). И ни на какой ленте эти инструкции не располагаются, они располагаются в "общем котле", и суть работы data-flow порцессора сводится к исполнению одних инструкций и порождению других как результат. Более того, в операциях, где участвует более одного операнда, эта инструкция оказывается "размазанной" по разным данным, и только когда в "общем котле" окажутся все операнды данной уникальной инструкции, все это собирается вместе и подается на вычислитель.

В принципе, коль ты так упираешь, все описанное на модель тьюринга ложится легко и просто, разумеется, ведь описан всего--лишь некий уровень абстракции, и не важно, программно он реализован, как в Форте/Лиспе/Яве, или аппаратано, как матчере дата-фло процессора, разве это интересно? Разве затем выдумываются языки высокого уровня, чтобы оперировать ячейками?

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

B>Так скажи как обозвать все вместе объекты, значения и инструкции.

Токены

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

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

К>>Ну раз инструкции получают управление и сами делают, всё что нужно, то мне больше добавить нечего.

V>Откуда такая непроходимость?

[cut]

Могу задать аналогичный вопрос.
В принципе ты сам пишешь про интерпретатор и абстрактную VM, т.е. фактически отделяешь "исполнителя кода" и код, но при этом у тебя функции сами себя выполняют.
Тогда как в лиспе — code is data, т.е. входные данные для некоего интерпретатора.
Но если вам нравится так смотреть — ради бога, только на мой взгляд это очень грубая логическая ошибка.
И никто при этом не отрицает языков высокого уровня, да и непонятно зачем и при чём тут ячейки?

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

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

B>>Так скажи как обозвать все вместе объекты, значения и инструкции.

PC_>Токены

Проверка выглядит так. В системе Lada все токены!
По аналогии все-объекты. Но, у нас же не все объекты. Звучит?

Будем ждать еще варианты.
Кстати, пришли свой док на vympel2001@yahoo.com
Мне не удалось открыть то, что скачал.

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

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

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

B>>>Так скажи как обозвать все вместе объекты, значения и инструкции.

PC_>>Токены

B>Проверка выглядит так. В системе Lada все токены!
B>По аналогии все-объекты. Но, у нас же не все объекты. Звучит?

B>Будем ждать еще варианты.
B>Кстати, пришли свой док на vympel2001@yahoo.com
B>Мне не удалось открыть то, что скачал.

прислал

B>>>Ситуация следующая. Мы выяснили что инструкции и значения не объекты. Я их объединил под общим названием потому что они формируются по общим правилам, и единому формату. Теперь возник вопрос как теперь мне все это называть? Объявляется конкурс. Жду предложений..

T>>Можно называть (сюрприз!) "инструкции" и "значения". Чем меньше своих слов придумано — тем лучше.
B>Так скажи как обозвать все вместе объекты, значения и инструкции.

Как обозвать вместе трактор, воздух и клетку? хм... Это разные вещи. Нет никакого смысла их объединять под каким-то названием.

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

T>>>Можно называть (сюрприз!) "инструкции" и "значения". Чем меньше своих слов придумано — тем лучше.
B>>Так скажи как обозвать все вместе объекты, значения и инструкции.

T>Как обозвать вместе трактор, воздух и клетку? хм... Это разные вещи. Нет никакого смысла их объединять под каким-то названием.
Еще труднее трактор, нежность и бегом.
Но, у нас есть общие свойства. Все это имеет двоичное представление, и формируется это представление по единым правилам из такого понятия как байт. Потому все имеет единый формат, и в памяти и для хранения.
Задача стоит так. Крылатое "все есть объекты", заменить на более подходящее по причине того, что не все у нас объекты. Вот это и смысл. У нас что-то конкретно есть. Как его назвать?

T>>>>Можно называть (сюрприз!) "инструкции" и "значения". Чем меньше своих слов придумано — тем лучше.
B>>>Так скажи как обозвать все вместе объекты, значения и инструкции.

T>>Как обозвать вместе трактор, воздух и клетку? хм... Это разные вещи. Нет никакого смысла их объединять под каким-то названием.
B>Еще труднее трактор, нежность и бегом.
B>Но, у нас есть общие свойства. Все это имеет двоичное представление, и формируется это представление по единым правилам из такого понятия как байт. Потому все имеет единый формат, и в памяти и для хранения.

На разных этапах жизни программы эти вещи имеют и не имеют каких-то общих свойств.

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

B>Задача стоит так. Крылатое "все есть объекты", заменить на более подходящее по причине того, что не все у нас объекты. Вот это и смысл. У нас что-то конкретно есть. Как его назвать?

То есть вам нужно крылатое выражение ради крылатости? Ещё раз: объекты, значения, инструкции. Вне какого-то осмысленного контекста (например про модель выполнения) эти вещи не имеют общего названия.

Вы сначала объясните (хотя бы себе) зачем нужно выражение "всё есть X". Зачем всё под одну гребенку. Что это даёт?

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

T>На разных этапах жизни программы эти вещи имеют и не имеют каких-то общих свойств.

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

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

T>>На разных этапах жизни программы эти вещи имеют и не имеют каких-то общих свойств.

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

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

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

Ещё пример — описание грамматики языка. Что-то вроде:

Statement := ForStmt | ReturnStmt | IfStmt | ...
Value := Integer | String | ...
Object := ...
Expr := Value | Object # вот здесь у объектов и значений есть общее имя — выражение

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

А в отрыве от контекста, повторю, нет смысла искать для них общее название. Потому что оно ничем не вооружает.

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

T>Да, вполне ответили. Смотрите выше про рассматривать разные этапы. При хранении и передаче, всё — данные. Значениями, объектами и инструкциями они становятся в работающей программе.

T>А в отрыве от контекста, повторю, нет смысла искать для них общее название. Потому что оно ничем не вооружает.
Вот я и предлагаю что б это было единым на всех этапах. От редактирования, транслирования и хранения. И даже написал как это делается. Посмотри введение. Только вот слово объект не подходит.

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

V>>Откуда такая непроходимость?

К>[cut]

К>Могу задать аналогичный вопрос.
К>В принципе ты сам пишешь про интерпретатор и абстрактную VM, т.е. фактически отделяешь "исполнителя кода" и код, но при этом у тебя функции сами себя выполняют.

Это ты решил поиграть в Капитана Очевидность?

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

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

А мы, коллеги, прекрасно понимаем, что "то-то и то-то" делает не сама ф-ия, а процессор, на который подали скомпиллированный из ЯВУ в объектное представление код, разложенный по сегментам, загруженный затем загрузчиком ОС, с подправленными адресами, с выделенной и настроенной таблицей виртуальной памяти для сегментов, с выделенным стеком для потока, и еще кучу вещей, на пару абзацев. И какой смысл говорить каждый раз об этих банальностях? Тем более, что если VM пишется на ЯВУ, то создатель самой VM абстрагирован от подробностей архитектуры конкретной машины, для него самым низким уровнем абстракции являются элементы используемого ЯВУ, для рассматриваемого случая — объекты и их методы. Как представлена инструкция в его VM? Да так же как ф-ия в Лиспе, в виде объекта. Как передается управление этой инструкции? Да вызовом некоего метода навроде eval(). Кто это вызывает? Его ядро, функциональность которого может быть размазана по разным объектам и этим "инструкциям" в том числе. В предыдущем сообщении показал пример из Лиспа, где работа VM, по-сути, происходит в коде пользовательских ф-ий, итерирующих ("вычисляющих" в терминах Лиспа) собственное тело.

ОК. С терминологией у человека не ахти, вместо термина "инструкция" лучше бы взял термин "операция" или "функция". ИМХО, сие не принципиально, ибо термин "инструкция" означает команда/директива, а представление команды необязательно должно быть в виде числового кода, как ты привык.

К>Тогда как в лиспе — code is data, т.е. входные данные для некоего интерпретатора.

Зато обратное неверно, что означает, что на лицо лишь частный случай представления кода. Например, в дальнейшем развитии Лиспа — Схеме, есть по стандарту компиляторы, так вот, где возможно, они из шитого кода тел ф-ий формируют машинный код, разворачивают хвостовые рекурсии и т.д. Тем не менее, и это важно, абстракция ничуть не меняется. Ты в праве равнозначно рассматривать код, исполняемый как интерпретатором, так и после компиляции.

К>Но если вам нравится так смотреть — ради бога, только на мой взгляд это очень грубая логическая ошибка.

Не обязательно окружающих считать идиотами.

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

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

V>>>Откуда такая непроходимость?

К>>[cut]

К>>Могу задать аналогичный вопрос.
К>>В принципе ты сам пишешь про интерпретатор и абстрактную VM, т.е. фактически отделяешь "исполнителя кода" и код, но при этом у тебя функции сами себя выполняют.

V>Это ты решил поиграть в Капитана Очевидность?

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

V>Обычно говорится, что данная ф-ия делает "то-то и то-то". Ну так принято, причем в таком ключе ведется даже начальное преподавание программированию.

V>А мы, коллеги, прекрасно понимаем, что "то-то и то-то" делает не сама ф-ия, а процессор, на который подали скомпиллированный из ЯВУ в объектное представление код, разложенный по сегментам, загруженный затем загрузчиком ОС, с подправленными адресами, с выделенной и настроенной таблицей виртуальной памяти для сегментов, с выделенным стеком для потока, и еще кучу вещей, на пару абзацев. И какой смысл говорить каждый раз об этих банальностях? Тем более, что если VM пишется на ЯВУ, то создатель самой VM абстрагирован от подробностей архитектуры конкретной машины, для него самым низким уровнем абстракции являются элементы используемого ЯВУ, для рассматриваемого случая — объекты и их методы. Как представлена инструкция в его VM? Да так же как ф-ия в Лиспе, в виде объекта. Как передается управление этой инструкции? Да вызовом некоего метода навроде eval(). Кто это вызывает? Его ядро, функциональность которого может быть размазана по разным объектам и этим "инструкциям" в том числе. В предыдущем сообщении показал пример из Лиспа, где работа VM, по-сути, происходит в коде пользовательских ф-ий, итерирующих ("вычисляющих" в терминах Лиспа) собственное тело.

То, что VM выполняет пользовательские функции, не делает VM этими самыми функциями.

V>ОК. С терминологией у человека не ахти, вместо термина "инструкция" лучше бы взял термин "операция" или "функция". ИМХО, сие не принципиально, ибо термин "инструкция" означает команда/директива, а представление команды необязательно должно быть в виде числового кода, как ты привык.

Переименование ничего бы не дало, про числовой код я нигде ничего не писал, зачем приписывать мне свои домыслы?

К>>Тогда как в лиспе — code is data, т.е. входные данные для некоего интерпретатора.

V>Зато обратное неверно, что означает, что на лицо лишь частный случай представления кода. Например, в дальнейшем развитии Лиспа — Схеме, есть по стандарту компиляторы, так вот, где возможно, они из шитого кода тел ф-ий формируют машинный код, разворачивают хвостовые рекурсии и т.д. Тем не менее, и это важно, абстракция ничуть не меняется. Ты в праве равнозначно рассматривать код, исполняемый как интерпретатором, так и после компиляции.

С чего вдруг обратное стало неверно? Я вполне могу использовать код как данные, тем более если мы практически стопудово работаем в рамках фон-неймановской архитектуры.

К>>Но если вам нравится так смотреть — ради бога, только на мой взгляд это очень грубая логическая ошибка.

V>Не обязательно окружающих считать идиотами.

Довольно самокритично, ошибаются все, а про идиотов в моих словах ничего не было.

P.S. Консенсуса не намечается, поэтому удалюсь.

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

К>То, что VM выполняет пользовательские функции, не делает VM этими самыми функциями.

Извини, но теперь точно непроходимость... Я же на пальцах уже объяснил на примере Лиспа и Форта. Там функциональность VM размазана по "встроенным" функциям/словам соответственно для Лиспа/Форта. Пользовательская ф-ия — это тоже встроенный объект, который содержит список других ф-ий, опять же, не важно, встроенных или нет, ибо они все имеют один и тот же интерфейс. Аналогично для Форта.

Понимаешь, все встроенные ф-ии, включая пользовательские, и составляют VM таких машин. Ибо, следи за руками, все пользовательские ф-ии представляют из себя экземпляры объектов одного и того же типа. И ты думаешь, что наличие у них списка других ф-ий как их тела — это принципиальное отличие пользовательской ф-ии от встроенной? Нет, среди встроенных тоже полно таких ф-ий, это практически все связанные с ветвлениями, циклами и аналогами switch. В каждой из таких ф-ий свой алгоритм вызова списка вложенных ф-ий, самый простой — у пользовательской, ибо там тупой перебор. Вот и получается, что вся VM — это просто набор объектов, имеющих идентичный интерфейс, которые вызывают друг друга, и тем самым осуществляют работу VM. Абсолютно точно так же у Форта, только там не объекты, хранящие свои данные, как ф-ии и замыкания в Лиспе, а слова Форта, то бишь адреса ф-ий в памяти. И для классического шитого кода все эти слова имеют идентичный интерфейс для своего вызова. И точно так же, вся VM Форта — это набор основных слов, причем встроенных там обычно совсем мизерное кол-во, эдакое мини-ядро, а остальные слова "системного плана" обычно писаны уже на самом Форте. Но без них полноценный Форт не работает, т.е. даже весь этот цикл read-eval организуется уже довольно высокоуровневыми словами. Вот и получается, что здесь тоже, слова (ф-ии) Форта составляют его VM.

Справедливости ради, многие реализации Лиспа тоже имеют эту особенность, то бишь цикл read-eval уже на самом Лиспе написан. Не знаю, переживет ли твой разум сие открытие, но выглядит все так, будто VM сама на себе написана... Угу, даже собственно ПАРСЕР, который считается чуть ли не основным элементом любого языка-интерпретатора...

К>Переименование ничего бы не дало, про числовой код я нигде ничего не писал, зачем приписывать мне свои домыслы?

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

V>>Зато обратное неверно, что означает, что на лицо лишь частный случай представления кода. Например, в дальнейшем развитии Лиспа — Схеме, есть по стандарту компиляторы, так вот, где возможно, они из шитого кода тел ф-ий формируют машинный код, разворачивают хвостовые рекурсии и т.д. Тем не менее, и это важно, абстракция ничуть не меняется. Ты в праве равнозначно рассматривать код, исполняемый как интерпретатором, так и после компиляции.

К>С чего вдруг обратное стало неверно? Я вполне могу использовать код как данные, тем более если мы практически стопудово работаем в рамках фон-неймановской архитектуры.

Обратно вообще-то — это данные как код. Следим внимательнее. Кстати, Лисп, как и Форт, могут работать и на гарвардской архитектуре. Достаточно, чтобы архитектура могла делать jump/call по адресу, полученному из области данных. Правда, для гарвардской получается не так эффективно для Форта, потребуется костыль, но реализовать можно. Даже на дотнете Форт сделали, но там вообще через ж-у, ибо стек возвратов эмулировать пришлось, а то верификатор не пропускает ф-ии, изменяющие указатель стека после своей работы.

К>P.S. Консенсуса не намечается, поэтому удалюсь.

Да откуда консенсус в терминологических спорах? Термины, они ведь как аксиомы, идут без доказательств, так что бесполезно что-либо доказывать.

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

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

S>Также, как и везде — есть форт-машина, которая исполняет инструкции.

А вот и нет, инструкции исполняет центральный процессор, даже в случае шитого кода.

В Форте вообще нет никакой внешней VM, она существует только в голове как элемент абстракции и как реализация цикла read-eval(-print). Там просто jump/call на слова Форта (инструкции), и вот они сами свой код и исполняют с т.з. этой абстрактной VM. Повторюсь, понятное дело, что тела этих инструкций исполняет процессор, или же низлежащая VM, если у нас некий Форт для Java/.Net, но этот уровень абстракции уже не интересен этой VM — с её уровня абстракции слова исполняются сами.

S>Архитектура машины внятно описана, instruction set — тоже. Наличие шитого кода никак не опровергает instruction immutability.

Так в Лиспе тоже, все ф-ии и замыкания иммутабельны, после создания их входным парсером, но представляют из себя объекты, даже если реализация Лиспа написана на С (классическая пара ф-ии+экземпляр структурированных данных). Чем Лада-то не угодила? Или тебя смущает, что иммутабельные объекты похожи на абстрактные типы данных? И что с того? Если в наличии ОО-язык, то АТД описываются с помощью ОО-конструкций.

Ибо, парадигма программирования и некий использованный ЯВУ не обязательно имеют идентичный набор характеристик, особенно если для разработки был использован язык общего назначения, типа VB.Net.

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

ИМХО, оно столько обсуждения не стоило. По мне термин "слово" для Форта — куда как более спорно.

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

Автору пока не хватает информации, но думает он в правильном направлении. Возможно, в процессе реализации задумки (если он ее не бросит) подтянется и профессионализм, он посмотрит на реализации других языков (знания об устройстве интерпретатора Лисп/Схемы must have, это уровень 0), и ему станет более ясна собственная концепция. Понятно, что тут работы не на год и даже не на два. Так же было бы интересно реализовать язык-близнец, но в С-подобном синтаксисе, ибо он гораздо популярнее, чем VB-подобный. Возможно, даже многое в этом синтаксисе станет людям понятнее по естественным причинам "натренированности" глаза.

Еще более интересно было бы "присосаться" к чему-то, допускающему расширения синтаксиса, чтобы реализовать концепции не на голой инфраструктуре, а на солидном фундаменте, например на Немерле. Тогда пошаговость и успешность работы на каждом шаге могут значительно повысить шансы всей разработки.

B>Обычно (и привычно) группирование объектов осуществляется скобками. Собственно для этого их и придумали. В системе используются круглые («)» и «(»), квадратные («[» и «]»),), фигурные («{» и «}»),), текстовые (««» и «»»),) и именные («"») скобки.
B>С назначением текстовых и именных скобок мы уже познакомились.

У тебя неправильный подход к объяснению. Ты вводишь понятие (группы) и начинаешь с того, как задать группу с помощью скобок. Это не академический подход, а подход в книжках типа "С++ за 21 час". Какая разница, какими скобками задаются группы, если у тебя все равно нет интерпертатора, в котором ты можешь попробовать?
Забудь про скобки для начала. Объясни, что такого группа. Зачем она нужна. В каких задачах группа могла бы быть полезной. И уже потом расскажи, что синтаксически группа задается так-то и так-то, вот пример.

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

V>А вот и нет, инструкции исполняет центральный процессор, даже в случае шитого кода.

Передергиваем-с?
Процессор исполняет свои инструкции. А не инструкции форт-машины.
V>В Форте вообще нет никакой внешней VM, она существует только в голове как элемент абстракции и как реализация цикла read-eval(-print).
Как, впрочем, и в дотнете.
V>Там просто jump/call на слова Форта (инструкции), и вот они сами свой код и исполняют с т.з. этой абстрактной VM.

Это реализация.
V>Повторюсь, понятное дело, что тела этих инструкций исполняет процессор, или же низлежащая VM, если у нас некий Форт для Java/.Net, но этот уровень абстракции уже не интересен этой VM — с её уровня абстракции слова исполняются сами.
И тем не менее, есть стек слов, есть стек данных, есть понятие текущей исполняемой инструкции. Это и есть описание состояния VM.

S>>Архитектура машины внятно описана, instruction set — тоже. Наличие шитого кода никак не опровергает instruction immutability.

V>Так в Лиспе тоже, все ф-ии и замыкания иммутабельны, после создания их входным парсером, но представляют из себя объекты, даже если реализация Лиспа написана на С (классическая пара ф-ии+экземпляр структурированных данных).
Для того, чтобы быть объектом, недостаточно иметь ссылку на функцию в экземпляре структурированных данных.

V>Чем Лада-то не угодила? Или тебя смущает, что иммутабельные объекты похожи на абстрактные типы данных? И что с того? Если в наличии ОО-язык, то АТД описываются с помощью ОО-конструкций.

Ибо, парадигма программирования и некий использованный ЯВУ не обязательно имеют идентичный набор характеристик, особенно если для разработки был использован язык общего назначения, типа VB.Net.
Но мы говорим не о конкретной реализации, а о "математике", которая лежит в основе. Например, в C++ нет понятия "интерфейс"; однако при проектировании некой системы имеет смысл различать классы и интерфейсы.
Последовательность использования терминологии — залог правильного понимания.

V>Я лично вижу, что идет неприятие исключительно из-за того, что базовый исполнительный элемент VM для языка Лада был обозван "инструкцией".
Неприятие идёт исключительно из-за того, что базовый исполнительный элемент был обозван "объектом". Из-за чего возникает множество некорректных утверждений, вроде "у любого объекта есть свойство Result".
А также из-за того, что базовые исполнительные элементы имеют изменяемое состояние; при этом в качестве примеров приводятся не интуитивно ожидаемые "аггрегатор" или "триггер", а старые добрые императивные for, if, и так далее.

Не "замыкание" как в Лиспе, ни "слово" как в Форте, а вот "инструкция".

ИМХО, оно столько обсуждения не стоило. По мне термин "слово" для Форта — куда как более спорно.
Дело не в спорности слова. Термин "слово" для Форта единожды определён, и используется непротиворечиво. В нём нет тенденции называть "словом" всё подряд.

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

Автору пока не хватает информации, но думает он в правильном направлении.
Возможно. Я пока фундаментальных проблем в самом языке не вижу. Я просто пока не могу понять, как именно это работает.

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

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

V>У тебя неправильный подход к объяснению. Ты вводишь понятие (группы) и начинаешь с того, как задать группу с помощью скобок. Это не академический подход, а подход в книжках типа "С++ за 21 час". Какая разница, какими скобками задаются группы, если у тебя все равно нет интерпертатора, в котором ты можешь попробовать?
V>Забудь про скобки для начала. Объясни, что такого группа. Зачем она нужна. В каких задачах группа могла бы быть полезной. И уже потом расскажи, что синтаксически группа задается так-то и так-то, вот пример.
Могет быть. Я подумаю.

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

V>>В Форте вообще нет никакой внешней VM, она существует только в голове как элемент абстракции и как реализация цикла read-eval(-print).
S>Как, впрочем, и в дотнете.

Да нет, в дотнете есть спецификация процессора с набором инструкций.

S>И тем не менее, есть стек слов, есть стек данных, есть понятие текущей исполняемой инструкции. Это и есть описание состояния VM.

Только стек данных и стек возвратов. Состояния стека и есть описание состояния. Понятия текущей исполняемой инструкции нет — это за рамками. Спецификации Форта вообще ограничиваются весьма высокоуровневыми вещами, в отличие от VM .Net.

S>>>Архитектура машины внятно описана, instruction set — тоже. Наличие шитого кода никак не опровергает instruction immutability.

V>>Так в Лиспе тоже, все ф-ии и замыкания иммутабельны, после создания их входным парсером, но представляют из себя объекты, даже если реализация Лиспа написана на С (классическая пара ф-ии+экземпляр структурированных данных).
S>Для того, чтобы быть объектом, недостаточно иметь ссылку на функцию в экземпляре структурированных данных.

Тем не менее, если в распоряжении ОО-язык, то все вокруг — объекты.

S>Но мы говорим не о конкретной реализации, а о "математике", которая лежит в основе.

Ну, с этим проблемы, и то, больше терминологического плана.

S>Например, в C++ нет понятия "интерфейс"; однако при проектировании некой системы имеет смысл различать классы и интерфейсы.

В С++ понятие интерфейса совпадает с оным для обычного ООП — это видимый АПИ типов. А различать стоит действительно интерфейсы (только не в рамках интерфейсов дотнета/явы/дельфи) и реализующие типы. В С++ со всем этим полный порядок, т.к. реализует несколько видов полиморфизма, в отличие от явы/дотнета.

S>Последовательность использования терминологии — залог правильного понимания.

К примеру, в Скала всё является объектом, даже int. И как-то гневной критики в их адрес не слышу...

V>>Я лично вижу, что идет неприятие исключительно из-за того, что базовый исполнительный элемент VM для языка Лада был обозван "инструкцией".
S>Неприятие идёт исключительно из-за того, что базовый исполнительный элемент был обозван "объектом".

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

S>Из-за чего возникает множество некорректных утверждений, вроде "у любого объекта есть свойство Result".

Наверно имелось ввиду "у любого объекта в такой-то иерархии". Да там вообще товарищ выдает много ненужных подробностей, которые сугубо относятся к реализации языка. Очевидно, ему плохо удается отделять спецификацию языка от реализации, и он перескакивает с одного на другое. Чего стоит только куча постов вокруг "FOR I", и о том, что I -имя цикла FOR. Это уже несущественные подробности метаинформации, и налицо наивная попытка сэкономить на спичках, ибо если I — имя цикла, то где же информация о типе итерируемой переменной. В общем, слабина в реализации видна невооруженным взглядом и вряд ли стоило эти моменты вообще обсуждать.

S>А также из-за того, что базовые исполнительные элементы имеют изменяемое состояние; при этом в качестве примеров приводятся не интуитивно ожидаемые "аггрегатор" или "триггер", а старые добрые императивные for, if, и так далее.

Ну дык, в Лиспе аналогично, без триггеров и агрегаторов. Функциональный язык под собой имеет сугубо ООП-реализацию, даже если на С (просто на слово поверь, я около 20-ти реализаций рассматривал подробно в разное время). Ибо каждая ф-ия в Лиспе "внутрях" — объект с данными и с промежуточными состояниями, и с неким единым "интерфейсом". И все это вместе реализует функциональную парадигму. И никакого противоречия, ибо разные уровни абстракции. Так же как и любой бинарник, порожденный компилятором самого что ни на есть чистого ФП-языка содержит последовательность императивных инструкций целевого процессора или VM.

S>Не "замыкание" как в Лиспе, ни "слово" как в Форте, а вот "инструкция".

ИМХО, оно столько обсуждения не стоило. По мне термин "слово" для Форта — куда как более спорно.
S>Дело не в спорности слова. Термин "слово" для Форта единожды определён, и используется непротиворечиво. В нём нет тенденции называть "словом" всё подряд.

Угу, всего лишь называют "словом" все, что может быть исполнено... Так же как и автором Лады относительно "инструкций".

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

Автору пока не хватает информации, но думает он в правильном направлении.
S>Возможно. Я пока фундаментальных проблем в самом языке не вижу. Я просто пока не могу понять, как именно это работает.

Ну так эти вопросы и надо было задавать:
— каков общий сценарий вызова событий?
— кто именно и в какие моменты производит группировку событий и вычисление предусловий?
— какой самый общий верхний цикл этой VM (на простейшем псевдокоде)?
— что с асинхронностью и многозадачностью?
— как определяется точка входа и где останов?

А то кучу экранов обсуждения всякой ерунды, если честно. Автор пока даже не в курсе, что именно не понятно.

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

S>Она говорит либо о том, что вы не различаете понятия "тип" и "значение", либо о том, что вы непоследовательно пользуетесь собственной терминологией.

О, наконец-то по делу! Дело в том, что в системе, когда у некоего типа может быть лишь единственный экземпляр, разница м/у типом и значением перетекают в область сугубо философскую. Ибо один экземпляр — это реально круто. Не больше (это фигня), но самое важное — не меньше, а ровно один, что означает, что одно без другого не существует и не имеет смысла, в отличии от системы, где на каждый тип может быть от 0-ля до оо экземпляров.

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

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

Пусть есть у нас некий объект Int32, имеющий св-во Value, типа.. Int32... Ну ты понял.

Это ничему не противоречит, коль у нас есть операция сравнения объектов, ибо не нужно до бесконечности "вынимать" св-во Value. Например, в некоторых системах без ATD простые булевы данные представляются через идентити двух объектов с глобальной видимостью: #t и #f. И речь идет о чистом функциональном языке, построенном сугубо на объектах. Не зря создатель этого языка в соседней ветке выступал как защитник ООП.

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

Есть, если (возвращаясь к нашим баранам) инструкции "сами себя исполняют". У самой верхней инструкции будет состояние-курсор текущей дочерней операции. Аналогичное поведение унутрях ф-ий Лиспа я уже упоминал. Фишка тут в том,что если вызов инструкции считать атомарным событием, то состояния как бы и нет, и оно нам непосредственно не доступно на некоем уровне абстракции. И это важно. Именно здесь лежит граница м/у функциональным и императивным вглядом на вещи. Но реально-то состояние есть, иначе такая фишка функционального программирования, как продолжения, без этого внутреннего состояния не работала бы.

S>Нет. Ничего очевидного тут нету. Ну вот к примеру — как же он превратится в исполняемый код, если без виртуальной машины он всё равно не может выполниться?

А чем реальная машина хуже виртуальной? И как это "объект не может выполнится"? Передай объекту управление, вызвав какой-нить метод, и все.

S>Ваш компилятор ничего подобного сделать не сможет — потому, что у for есть какой-то Result, который нужно менять при исполнении, даже если внутри цикла ничего не происходит.

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

	От:	batu
	Дата:	13.03.10 20:59
	Оценка:

	От:	vadimcher
	Дата:	13.03.10 21:25
	Оценка:

	От:	Dufrenite
	Дата:	13.03.10 21:34
	Оценка:

	От:	pgregory
	Дата:	13.03.10 21:54
	Оценка:

	От:	deniok
	Дата:	13.03.10 22:10
	Оценка:	+12

От:	VladD2	www.nemerle.org
Дата:	13.03.10 22:23
Оценка:	39 (4) +2

	От:	Temoto
	Дата:	13.03.10 22:44
	Оценка:	85 (6) +4

От:	A.Lokotkov	http://www.linkedin.com/pub/alexander-lokotkov/a/701/625
Дата:	14.03.10 06:16
Оценка:

	От:	Мишень-сан
	Дата:	24.03.10 08:15
	Оценка:	+3

От:	Фанатик	http://vk.com/id10256428
Дата:	24.03.10 10:51
Оценка:

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	26.03.10 22:16
Оценка:	+2

	От:	cl-user
	Дата:	07.04.10 07:53
	Оценка:	1 (1) +3

От:	Курилка	http://kirya.narod.ru/
Дата:	08.04.10 08:12
Оценка:

От:	D. Mon	http://thedeemon.livejournal.com
Дата:	03.08.10 04:32
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	03.08.10 08:36
Оценка:	+2

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	02.09.10 19:57
Оценка:	+3

	От:	Mr.Cat
	Дата:	04.09.10 12:25
	Оценка:	34 (1) +1

От:	Sinclair	https://github.com/evilguest/
Дата:	11.09.10 05:37
Оценка:

От:	PC_2	http://code.google.com/p/rsinterpretator/
Дата:	21.09.10 09:40
Оценка:

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