1

Тема: «Hello, world!» из объектно-ориентированной ОС

С открытием форума решил вытащить на него черновики статей блога, не прошедшие модерацию или не доведенные до публикации по иным причинам. Эта статья изначально писалась с целью дальнейшего перевода на английский язык, чтобы стать первой англоязычной статьей в блоге (см. также Cantor Language Features), но перевод был признан неудачным и не публиковался, а русский исходник не совсем подходит под формат блога, как мне тогда показалось.


favicon.ico favicon.ico favicon.ico

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

Кантор разрабатывается как компилируемый язык и язык системного программирования, но основан на функциональной и объектно-ориентированной парадигмах. Цель — создать новые направления системного программирования: функциональное системное программирование и объектно-ориентированное системное программирование, а затем разработать перспективную ОС, которая не будет копией уже имеющихся.

Далее речь пойдет об альфа-версии Кантора, разрабатываемого на Delphi как интерпретатор — это первый шаг к самораскрутке компилятора. Со временем Кантор будет переписан на Канторе и научится собирать сам себя.

Уже на этапе альфа-версии важно проработать ключевые понятия чистой объектно-ориентированной среды, поскольку на первых порах роль объектно-ориентированной ОС будет выполнять сам Кантор. Для этого всем выбранным теориям нужно найти практическое воплощение, попутно переосмысливая привычные понятия ОС.


Hello, world!

В альфа-версии Кантора программа «Hello, world!» будет выглядеть так:

return 'Hello, world!';

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

favicon.ico Понятия файла и консоли, а также встроенных в язык операторов или функций ввода-вывода.

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

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

Получается, что на «Hello, world!» отрабатываются основы функционального программирования. Программы-процедуры появятся чуть позже, для них нужно больше работы.

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

favicon.ico Объектно-ориентированная ОС абстрагирует двоичные интерфейсы и контейнеры так же, как концепция UNIX абстрагирует текстовый ввод-вывод и консоль.

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


Класс как единица трансляции

Вполне логично, что в объектно-ориентированной ОС единицей трансляции должен быть класс, при этом программа «Hello, world!» должна оставаться прежней:

return 'Hello, world!';

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

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

class of
  return 'Hello, world!';
end;

При этом оператор return вне функции должен что-то означать, иначе получается, что ради «Hello, world!» мы придумали особую конструкцию, типа как с вводом-выводом в Паскале.

На данный момент return внутри класса считается объявлением одного из умолчательных итераторов, доступных оператору inner. Это похоже на представления в БД. Класс может иметь несколько перегруженных итераторов. Раз уж в Канторе каждый класс считается потенциальным контейнером, доступ к их содержимому должен быть прост и единообразен, так что return внутри класса — такая же общая конструкция, как return внутри функции.

Среда будет исполнять анонимный класс-программу следующим образом:

  • Создается экземпляр класса, его содержимое перечисляется итератором без параметров, возвращающим строку (это соглашение вызова, ведь итераторов может быть несколько).

  • Полученные строки выводятся службой вывода среды: в консольном приложении — на консоль, в GUI — пока не придумал куда.

  • Итератор «Hello, world!» возвращает одну строку, поэтому в консоль выводится одна строка.

  • Экземпляр выходит за пределы видимости среды и уничтожается.

В компиляторе эти шаги будут компилироваться в качестве процедуры точки входа — аналога main() в Си.

Тем самым выполняются все требования Кантора: только ООП, строгая типизация, отсутствие неявных умолчаний и предопределеных имен. Точка входа архитектурно оформлена как анонимная функция — в ОС это ведь просто адрес внутри исполняемого файла.

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


Двоичные сборки исходного кода

В теме «Hello, world!» мы рассматриваем также работу обратимого кода — двоичного аналога распространяемых исходных текстов. Раз ОО-система абстрагирует двоичные интерфейсы, то и исходный код ее — двоичный. Обратимый код такой среды нужно сравнивать не с байт-кодом Java, а с Gentoo или NPM-пакетами Node.js. Все их принципы тут применимы.

Разработка на Канторе строится на том, что любой класс из обратимого кода всегда можно превратить в текст, посмотреть глазами, исправить и установить обратно, то есть носит характер патчей, но с полным контролем со стороны среды. Где используется этот класс? Запрос! Можно ли перегрузить это свойство, не поломается ли код? Запрос! Можно ли добавить параметр со значением по умолчанию в функцию? Запрос! И так далее.

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

Ибо нельзя просто так взять и добавить ООП на системный уровень — это неизбежно смещает акценты. Ведь если подумать, классические ОС построены на парадигме монолитов: монолитные программы, монолитные файлы, монолитные API и т. п. В этих условиях текст — единственный монолитный формат, доступный для изменения человеком, поэтому всё идет через текст и человеческий разум. Человек — самый гибкий компонент любой системы.

А во фрактальной ОС нет монолитов. Она рекурсивна, и четкой грани между языком и ОС нет. На первых порах функции ОС берет на себя сам Кантор, следя за наследованием, полиморфизмом и агрегацией через обратимый код. Именно эти функции были возложены на ядро объектно-ориентированной ОС. Концепция СУБД, взятая за основу — прекрасный пример гибкой и нерутинной работы с данными, которые нельзя охватить механически, вручную.

В целях безопасности на будущее в Канторе запланированы СУБД-шные права доступа, раз уж код — это БД. Будет право на использование, на изменение, на добавление, на наследование, на удаление и пр.

В продолжение темы пакетов в следующий раз, наверное, нужно рассказать о проекции пространств имен на файлы и каталоги, то есть как файлы и каталоги исходников превращаются в пространства имен в среде Кантора. Тема уже выходит за рамки «Hello, world!», состоящего из одного файла, но закладывается в обратимый формат и будет реализовываться сразу после выхода первой альфы.

2

Re: «Hello, world!» из объектно-ориентированной ОС

Статья идеально подходит в блог, на мой взгляд.

3

Re: «Hello, world!» из объектно-ориентированной ОС

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

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

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

Добавлено 03.07.2015 в 13:10

Комментарий из темы "Предварительные объявления в C++, Java, Аде и Канторе" на OSDev.ru:

Freeman пишет:
SII пишет:

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

А вы подумайте и попробуйте понять, чем вызвано такое мнение. Предполагаю, что это обычный наведенный эффект от пользования гибридными языками, в которых ООП неизбежно связано с накладными расходами. ОО-системы с объектами первого класса существуют пока только в виде интерпретаторов и/или замкнутых миров, вроде Smalltalk/Squeak, так что Кантор, вероятней всего, будет первой такой системой на компилируемом языке.