1 (изменено: Freeman, 15.05.2017 в 16:18)

Тема: Объектная алгебра (ранее — контейнерная арифметика)

Это первая тема по концепции контейнерной арифметики в Канторе. Сам термин "контейнерная арифметика" -- внутренний термин Кантора, обозначающий совокупность обобщенных операций по обработке контейнеров, сделанных по аналогии с SQL. Сюда входят:

  • Итераторы, обход деревьев и графов (аналог map).

  • Внешние и внутренние объединения (декларативный аналог map для данных).

  • Пересечение, вычитание, объединение и прочие операции из теории множеств.

  • Группировка и агрегатные функции (reduceсвертка).

  • Сортировка значений.

Главное отличие контейнерной арифметики от SQL — работа с произвольными контейнерами, а не только с таблицами и представлениями, поскольку СУБД-шных таблиц и представлений в Канторе нет.

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

В компиляторе Кантора итераторы будут напрямую порождать машинный код, а не эмулироваться библиотекой, тем самым играя ту же роль, что и представления в СУБД.

2

Re: Объектная алгебра (ранее — контейнерная арифметика)

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

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

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

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

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

Для развития темы нужно придумать примеры вычисления каких-нибудь последовательностей и рядов и записать их на Канторе.

3

Re: Объектная алгебра (ранее — контейнерная арифметика)

Freeman пишет:

Главное отличие контейнерной арифметики от SQL -- работа с произвольными контейнерами, а не только с таблицами и представлениями, поскольку СУБД-шных таблиц и представлений в Канторе нет.

По большому счету, SQL также оперирует произвольными множествами. В умных книжках советуют при его изучении "thinking in set".
Или имеется ввиду только физическая реализация? Если так, то можно придумать кучу разных способов, когда SQL получает множества из функций, из удаленных источников, в результате вычисления программ в dll на худой конец.

4 (изменено: Freeman, 03.07.2015 в 0:35)

Re: Объектная алгебра (ранее — контейнерная арифметика)

kdenis пишет:

По большому счету, SQL также оперирует произвольными множествами. В умных книжках советуют при его изучении "thinking in set".

Тут нужно учитывать, что множества SQL неупорядочены, поскольку основаны на реляционной парадигме. Для прямого доступа реляционным множествам нужны индексы, для уникальности элементов -- первичные и уникальные ключи, а для упорядоченности -- явно заданный оператор order by, эти самые индексы и ключи использующий. СУБД, по сути, сводит множества к единственной реализации -- таблице с полями, доступ к которой легко может быть скрыт за магией среды.

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

Я не уверен, но вполне возможно, что внутренняя упорядоченность -- это именно то, что отличает объектно-ориентированную БД от реляционной. Кроме того, поскольку всё есть контейнер, объектно-ориентированная БД не делает различий между таблицей и полем, и если попытаться адаптировать SQL к ОО-среде, это непременно придется учесть. В Канторе это выливается во from из любого выражения, без явно заданного select.

В ранних версиях Кантора

В ранних версиях синтаксиса Кантора -- наоборот, был select откуда угодно, а смысл from еще был неясен. Но с первого дня было понятно, что в объектно-ориентированной СУБД select и from -- одно и то же.

Добавлено 05.07.2015 в 16:49

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

Добавлено 11.09.2015 в 12:37

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

5

Re: Объектная алгебра (ранее — контейнерная арифметика)

Хорошую задачу нашел:

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

В рамках этой темы ее нужно решить на SQL и на Канторе. Можете попробовать на других языках, в том числе своих, если хотите. Надеюсь, не утонем. smile

6

Re: Объектная алгебра (ранее — контейнерная арифметика)

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

Это не единственная функция циклов, иначе были бы только for-each

В этом смысле понятие контейнера в Канторе близко понятию списка в Лиспе, с той разницей, что Кантор не ограничивается списками.

Так и Лисп не ограничивается списками. Там чего только не понапихано. Списки исторически были первыми.

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

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

Для развития темы нужно придумать примеры вычисления каких-нибудь последовательностей и рядов и записать их на Канторе.

Факториал однако. Удобен потому что в функциональных языках программирования часто используется как учебный пример вместе с числами Фибоначи.

7

Re: Объектная алгебра (ранее — контейнерная арифметика)

utkin295 пишет:

Факториал однако. Удобен потому что в функциональных языках программирования часто используется как учебный пример вместе с числами Фибоначи.

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

8 (изменено: Freeman, 15.05.2017 в 17:54)

Re: Объектная алгебра (ранее — контейнерная арифметика)

Наконец-то я могу сказать, для чего нужна объектная алгебра — для отделения данных от вычислений в реализациях. В объявлениях данные отделяются от вычислений классами и функциями, а в реализации — объектной алгеброй. Таким образом программа — (фрактальный) набор узлов — пересечений данных с вычислениями. Это переосмысление формулы Вирта "алгоритмы + структуры данных = программы" на современном технологическом уровне, через ФП и ООП.

Добавлено 15.05.2017 в 15:48

И вдогонку. Объектная алгебра — это альтернативная реализация концепции функций первого класса в языке без ссылок на код, что сделано для упрощения частичных вычислений (суперкомпиляции). Логично, что раз данные и вычисления концептуально разделены и пересекаются в строго заданных точках, организовать их частичное вычисление будет намного проще, чем продираться через функции по ссылкам.

Добавлено 15.05.2017 в 16:22

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

Добавлено 15.05.2017 в 18:05

Если структуры данных и вычисления (алгоритмы?) концептуально разнесены, имеет смысл говорить об аналоге гарвадской архитектуры в языке программирования. Цель ее в том, чтобы иметь возможность анализировать структуры данных отдельно от процедур их обработки, делая структуру самодостаточной и самоценной, как происходит в СУБД.

Собственно, с первого дня Кантор развивался как язык описания данных, язык обработки данных и язык написания программ, описываемых терминами "декларативный синтаксис" и "командный синтаксис", то есть синтаксисов изначально было два. С развитием это оформилось в современные концепции, а синтаксисов стало бесконечно много, в соответствии с правилом счета в СУБД (null, 1, много).