1 (изменено: Freeman, 20.11.2018 в 20:57)

Тема: Абстрактный объектный вычислитель (машина платформы Кантора)

При разработке платформы имеет смысл говорить о машине Кантора как о неком абстрактном исполнителе, являющимся идеальной вычислительной машиной.

Машина Кантора является высокоуровневой. В ее основе, по всей видимости, лежит язык/архитектура (?) формальных грамматик, что логично: платформа обобщения исходных текстов должна опираться на язык формальных грамматик.

Как вычислитель машина Кантора характеризуется:

  • Тремя командами: define, match и when (определение, сопоставление и ветвление, соответственно). Названия команд могут измениться.

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

  • Бесконечным числом безразмерных (объектных) регистров.

  • Виртуальными стеками возвратов и данных, реализуемыми исполнительной средой. Стек данных также является объектным.

  • По всей видимости, бесконечным числом исполнительных потоков.

Наверное, самым большим отличием от других машин является отсутствие памяти. Обрабатываемые данные хранятся исключительно в объектных регистрах, обеспечивающих инкапсуляцию и фрактальность: любой регистр может быть разбит на бесконечное множество вложенных подрегистров (как в IA-32 AX делится на AH и AL).

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

Множество статусов чем-то похоже на ARM или некий супер-ARM в полном режиме, не thumb. При этом в Канторе команд всего 3, а регистры безразмерные.

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

С момента появления еще в 3OS концепции единого пространства данных хранение на линейных носителях выделено в особое пространство, обмен с которым происходит через диспетчер, обеспечивающий свертывание из регистров в линейные последовательности и развертывание при загрузке в регистры. Диспетчер будет использоваться в реализациях машины Кантора на существующих платформах и будет вполне традиционным: аллокатор/диспетчер кучи в ОЗУ и подсистемы сериализации для обмена с носителями длительного хранения и сетями. Реализации будут должным образом абстрагированы.

Нетрадиционные архитектуры процессоров

Есть предположение, что машина Кантора будет лучшим выбором (по сравнению с фон-нейманом в трактовке Си) для реализации на нетрадиционных архитектурах, типа в VLIW или мультиклеточной. Вопрос требует проработки, мнение может оказаться ошибочным.

Добавлено 17.11.2018 в 9:14

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

Ленточный вычислитель

Авторы дают своим детищам схематические названия.

Уточнения и замечания по сути и используемой терминологии принимаются.

2 (изменено: Freeman, 18.11.2018 в 08:02)

Re: Абстрактный объектный вычислитель (машина платформы Кантора)

React/Redux

В свете предложенного описания по-другому стали читаться вопросы в интернетах. Например:

webe пишет:
На хуках?

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

Нужен ли теперь Redux как отдельная библиотека? ведь теперь у нас есть useReducer и новый контекст.
Нужен ли MobX? (если писать в новом стиле реакта, он более ООП направленный)

Anton Filippov пишет:

стоит. Но это не убивает полностью стейтфул компоненты и тем более редакс/мобх

Спойлер и курсив мои. Почему-то кажется, что происходящее в React/Redux имеет какую-то опосредованую связь с предложенным вычислителем и декларативным ООП. И прототипным программированием еще, раз тут JS... Что-то вроде того, что разработчики JS чисто эмпирически ищут сформулированный нами философский камень, попутно решая свои практические задачи...

Было бы здорово, если бы в теме отписался кто-то, владеющий ситуацией. Если сильно отклонимся, всегда можно выделить ветку обсуждений. Здесь гибкий подход к понятию офтопика.

3

Re: Абстрактный объектный вычислитель (машина платформы Кантора)

Из сегодняшнего дня видится, что на модель вычислителя с бесконечным числом регистров естественным образом ложатся транзакции (при реализации регистров линейной памятью):

  • Загрузка абстрактного регистра в физическую память — начало транзакции.

  • Сохранение из памяти обратно в абстрактное представление — фиксация транзакции (commit).

  • Где-то должен быть и откат (rollback) — очистка объектного регистра без сохранения изменений.

Пока трудно представить, как будет на самом деле, в реальной машине Кантора. Соответственно, нельзя сказать, прав я или нет.

Похожая по смыслу концепция/разработка описана в Википедии — программная транзакционная память. Вопрос еще требует обдумывания и проработки.

4

Re: Абстрактный объектный вычислитель (машина платформы Кантора)

Dataflow-архитектуры. Часть 1:

В архитектурах с управлением потоком данных (Dataflow) [01] отсутствует понятие «последовательность инструкций», нет Instruction Pointer'а, отсутствует даже адресуемая память в привычном нам смысле. Программа в потоковой системе — это не набор команд, а вычислительный граф. Каждый узел графа представляют собой оператор или набор операторов, а ветви отражают зависимости узлов по данным. Очередной узел начинает выполняеться как только доступны все его входные данные. В этом состоит один из основных принципов dataflow: исполнение инструкций по готовности данных.

5

Re: Абстрактный объектный вычислитель (машина платформы Кантора)

Как перевести этот термин на английский?

favicon.ico  Абстрактный объектный вычислитель — abstract object computer.

Не уверен в переводе «вычислитель» — computer, но других вариантов не вижу... На английском определение дает совершенно другой акцент. Гм, можно ли уже говорить об импортозамещении и возврату к исконным смыслам?

Прибить гвоздями кириллицу к ИТ

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

Re: Абстрактный объектный вычислитель (машина платформы Кантора)

Без описания абстрактного ассемблера для абстрактного объектного вычислителя разговор беспредметен.

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

7

Re: Абстрактный объектный вычислитель (машина платформы Кантора)

Маздайщик пишет:

Без описания абстрактного ассемблера для абстрактного объектного вычислителя разговор беспредметен.

Код ассемблера — везде на сайте и на форуме. Ассемблер этой платформы — Кантор. Никакого другого ассемблера не предполагается. Перечисленные в заглавном сообщении понятия относятся, скорее всего, к реализации компилятора/машины. Всё это будет в коде компилятора Кантора.

Бесконечное число регистров — метафора для описания модели объектов (данных) в машине Кантора. Можно назвать их и памятью. Кантор не является машиной Тьюринга, как понимаю. У Тьюринга линейная память, любая ее ячейка может быть адресована из кода. В Канторе память... фрактальная. Объекты ссылаются друг на друга неким строго контролируемым образом, адресация произвольной ячейки запрещена. Самих ячеек тоже нет, есть фрактальные объекты, агрегирующие подобъекты бесконечного уровня вложенности в соответствии с декомпозицией/агрегацией, определенной программистом в конкретном наборе классов. Правильность агрегации проверяется и гарантируется ядром. Следовательно, никаких ячеек Тьюринга.

Наверное, описание в виде фрактальной памяти больше соответствует модели машины Кантора. Бесконечные регистры должны ссылаться друг на друга, чего в обычных регистрах нет. В этом случае машина Кантора должна содержать некий встроенный VHDL-процессор, модифицирующий регистры во время выполнения программы... Метапроцессор какой-то...

Если способ хранения объектов назвать фрактальной памятью, регистров в Канторе вообще нет, всё хранится в памяти.

ОС «Фантом»

Смешно, но это похоже на ОС «Фантом», где есть глобальная энергонезависимая память, управляемая машиной снимков и глобальным сборщиком мусора. «Фантом» ранее позиционировался как объектно-ориентированная ОС, так что в некотором смысле наш конкурент.

Re: Абстрактный объектный вычислитель (машина платформы Кантора)

Я говорю о том, что описание любого объектного вычислителя включает в себя не только описание данных, но и описания конечного числа способов преобразования этих данных.

Машина Тьюринга. Данные: конечный набор символов на бесконечной ленте + позиция головки над лентой. Операции: перезапись символа под головкой со сдвигом головки на одну ячейку вправо/влево.

Нормальные алгорифмы Маркова. Данные: строка в конечном алфавите символов. Операция: замена подстроки в соответствии с нормальным алгорифмом.

Лямбда-исчисление. Данные: выражение, собранное из переменных, абстракций и аппликаций. Операции: правила редукции этих выражений.

JVM (да, он уже не совсем абстрактный). Данные: данные языка Java + стек. Операции: опкоды JVM.

Стандарты C и C++ определяют абстрактные вычислители соответствующих языков.


Абстрактному объектному вычислителю Кантора не хватает конкретного описания операций над фрактальной памятью.


Кроме того, к фрактальной памяти вопросы. Чем она по сути отличается от объектной памяти языка Java?

class Tree {
  object key;
  object value;
  Tree left, right;
}

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

9

Re: Абстрактный объектный вычислитель (машина платформы Кантора)

Маздайщик пишет:

Абстрактному объектному вычислителю Кантора не хватает конкретного описания операций над фрактальной памятью.

Боюсь, конкретное описание операций возможно только после реализации. Эдакий development-driven design. Операции define, match и when, описанные выше без детального раскрытия, — всё, что есть на данный момент.

Маздайщик пишет:

Кроме того, к фрактальной памяти вопросы. Чем она по сути отличается от объектной памяти языка Java?

class Tree {
  object key;
  object value;
  Tree left, right;
}

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

Фрактальность заключается в подходе. Кантор основывается на объектно-ориентированной базе данных. Модель Java с точки зрения Кантора — моментальный снимок (snapshot). Развитие модели идет только в исходных текстах, общего правила нормализации классов нет.

Модель в Канторе — непрерывно развивающийся процесс. По мере развития классы распадаются на специализированных предков, и ранее единые классы становятся наследниками одного или нескольких новых предков. Если специализированность классов (и число предков) считать единицей измерения, точность измерения возрастает с каждой итерацией — с появлением каждого специализированного предка.

Насчет объектов сходу сказать не могу. Объект в Канторе — частный случай контейнера. По мере появления новых классов модель данных также будет изменяться, и ранее единые объекты станут контейнерами более мелких. Например, байт станет контейнером (агрегатом — это тоже контейнер?) битов, а единый PE-файл станет контейнеров своих компонентов (в том числе контейнером секций, тут уже точно). «Распад» PE-файла в конкретном экземпляре модели (системе) произойдет при установке классов компонентов PE, точнее описывающего существующие файлы. Такой класс, наверное, будет идти в наборе компонентов для программирования.

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

Для машины Кантора такая фрактальность — необходимость перестройки модели при установке нового класса, чтобы соблюсти все ограничения и не порушить модель. Правила игры остаются неизменными... Хотя, возможно, да, чем это отличается от Java? Ее, насколько понимаю, можно считать частным случаем виртуальной объектно-ориентированной ОС... Тогда принцип фрактальности («фрактальности»?) применим и к ней? Другое дело, что в Java не ставят классы, расширяющие общую модель, а не конкретную программу (не могу сказать про Android), а в Канторе это единственный способ развития. Тогда программа Java — конкретный экземпляр виртуальной объектно-ориентированной ОС? И ОС ли вообще?