OSDev

Всё-таки в Unix-е файловые функции ввода-вывода умеют работать с консолью, если при вызове функций в качестве файлового объекта использовать объект консоли. В Сишной библиотеке для этого есть глобальные переменные stdin, stdout и stderr.

Пока не спится, попробую написать про класс как единицу трансляции, как говорил. Программа "Hello, world!" остается прежней:

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

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

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

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

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

• Создается экземпляр класса, его содержимое перечисляется итератором без параметров, возвращающим строку (это соглашение вызова, ведь итераторов может быть несколько).
• Полученные строки выводятся службой вывода среды: в консольном приложении -- на консоль, в GUI -- пока не придумал куда.
• Итератор "Hello, world!" возвращает одну строку, поэтому в консоль выводится одна строка.
• Экземпляр выходит за пределы видимости среды и уничтожается.

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

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

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

Это сообщение не с первого раза получилось написать. Зарылся, отложил, обдумал и смог закончить. Часа два потратил.

_________________
Путь успеха Циолковского — правильно умереть

Сами кашу заварили, потом расхлёбывать будете!
Зачем усложнять код! И кому он нужен? Зачем транслировать функцию в класс с функцией? Я бы ещё понял если бы вы избавились от контексной константы. Не прощели признать что теперь код обязан быть ООП и сказать что мы меняем пример Hello word? Либо разделить языки и сферы их применения.

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

Немного оффтопа на тему концепции чистой ОО-программы.
Анализируя N+1-ю китайскую java-поделку я понял, что java, где задумывалась чистая ООП-шность всего языка (не важно, насколько это реализовано), имеет интересную особенность. Когда программа есть множество классов, в нее очень легко подсунуть не предусмотренный разработчиком код.
Например, если я верно понял концепцию Кантора, то элементарно (чуть ли не батником) можно провернуть следующие шаги:
1) Разобрать исполняемый файл (он ведь дерево классов?);
2) Найти в корневом классе определение множества его итераторов;
3) Добавить свой итератор и собрать назад;
В наше время такое сделают даже школьники. Так что получается, что любую программу элементарно можно модифицировать после компиляции, не имея почти никаких знаний. Антивирусники и проприетарщики "спасибо" не скажут.

А по поводу потока и консоли - мне похожие мысли в голову приходили. Почему именно консоль? Почему текст? Машина с числами работает, в крайнем случае - с объектами. А значит и стандартом выходных данных должна быть не куча текста в консоли, а бинарные данные. В противном случае получается, что при необходимости разобрать вывод одной программы в другой, мы делаем 2 тяжелых бесполезных действия: сначала конвертируем всё в текст, чтобы напечатать в несуществующую (скрытую) консоль, а потом во второй программе конвертируем текст назад в бинарные данные.
Но как именно это реализовать, я пока не особо задумывался. На мой взгляд, есть два решения.
1) Сделать аналоги print'а для бинарных данных. Они в выходной поток пихают бинарные данные как цельный объект. И читать их можно оттуда тоже как цельный объект, или же по частям.
2) Принудить все функции не гадить в консоль (для этого есть логи), а возвращать значение. Сама программа тоже может вернуть значение (любое).
У первого подхода плюс - это потоковость (не надо весь вывод держать в памяти, можно сделать так, чтобы одна программа туда писала, а другая параллельно читала). У второго плюс - структурированность: программы могут легко вызывать друг друга, как функции, и получать их возвращаемые значения.

Если пойти по накатанной, получится еще один C++ или PowerShell. А они кагбэ есть, еще один не нужен. Кантор просто обязан быть декларативным, декларативность с ООП еще никто не предлагал.

_________________
Путь успеха Циолковского — правильно умереть

среди тысяч искусственных языков обязательно найдётся. Попробуйте посмотреть стимул - объектный Алгол

Как раз очень важно, как это реализовано.

В теме "Hello, world!" мы рассматриваем работу обратимого кода -- двоичного аналога распространяемых исходных текстов. Раз ОО-система абстрагирует двоичные интерфейсы, то и исходные тексты ее -- двоичные. Обратимый код нужно сравнивать не с байт-кодом Java, а с Gentoo. Все принципы Gentoo тут применимы. Много ли школьников внедрило свой код в Gentoo и поломало Пентагон?

Да, в Канторе возможны вирусы типа Induc, но ему нужен доступ к машине разработчика и невнимательность разработчика. Это я не контролирую.

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

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

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


Для двоичного межпрограммного интерфейса нужна ма-а-аленькая деталь -- общесистемная RTTI. Только с ней списки можно передавать как списки, строки -- как строки, и всё остальное тоже. Библиотеки типов COM были шагом в правильном направлении, но на революцию Microsoft не потянула. Да и зачем? Конкурентов ведь нет... Додумывайте сами.

Ну а гадить в консоль функции на Канторе не смогут из-за ФП. Можно, конечно, и на Канторе писать чисто процедурно, но зачем?

_________________
Путь успеха Циолковского — правильно умереть

Вот вы смотрите, делайте анализ и выводы, почему он не взлетел. Потом напишете сюда, просветите нас.

_________________
Путь успеха Циолковского — правильно умереть

Сравнение с Gentoo не верно. Gentoo - ОС. А на ЯВУ (в т.ч. на Канторе) разрабатываются прикладные приложения. ОС ставится в среднем раз в несколько лет (а у некоторых - и раз в жизнь компьютера). Прикладных программ - тысячи и миллионы. А может и миллиарды. Поэтому распространять вредоносы в ОС - бесполезно, а в прикладном ПО - весьма прибыльно. Ну серьёзно, кто будет писать в гугле "Gentoo скачать бесплатно без смс"? Для ручных инфекций нужно ПО, оф. версии которого не устраивают людей (рекламой, оплатой, "отсутствием читов" и т.д.), чтобы создать поток людей на левые источники. Много ли такого среди опенсорца?
И писать непосредственно вирус сейчас малопродуктивно. Абсолютное большинство малварь - троянцы. Если взять андройд, то очень популярная практика такова: берем какой-нибудь ЭнгриБердс, вырезаем рекламу (ведь любой объект/пакет(java) можно легко выпилить), добавляем малварку вроде отправки смс на короткие номера (ведь любой объект/пакет(java) можно легко добавить), собираем назад и распространяем под названием "ЭнгриБердс без рекламы скачать бесплатно без смс". В андройде это делается просто элементарно двумя батниками и одной почти стандартной тулзой. Кантор в этом плане будет просто раем для малварщиков: скачал любую программу, модифицировал вредоносом-шпионом, выложил на разные порталы. С PE-шниками, к примеру, не так всё просто: вставка кода приведет к тому, что поедут все смещения, поэтому надо добавлять секцию и переписывать асм-команды, делать хитрую точку входа и так далее. Все это можно пропалить, и все это требует особых знаний и навыков. Но это так, лирическое отступление, информация к размышлению. Если Кантор будет также "популярен" в массах, как линукс, то малвара ему не грозит. А если все же будет подбираться по популярности к мейнстримовым языкам - стоит задуматься.

Разумеется, нужна обязательно. Хотя бы базовые типы (числа, массивы, структуры). Это один из пунктов ToDo моей ОС.
Но касательно Кантора - можно же реализовать библиотеки на канторе, которые могут подгружаться только в канторовые программы, и работать уже с этой технологией. Да, неполноценно, не общесистемно, но все же лучше, чем ничего. А если на этой базе будет ОС, то написание RTTI в системе проблем не составит, ведь оно, как я понимаю, и для самого Кантора понадобится.

ЗЫЖ на счет опенсорца - вроде был такой серверный чудо-вирус, который на сервере выкачивал исходники апача, добавлял в них свой код и перекомпилировал...

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

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

Даже не знаю, с чем еще сравнить можно... С сайтами? В PHP phar не прижился. А npm-пакеты где, в Node.JS? Они же вроде обратимы? Но всё равно всё человеком контролируются, а не средой. А в человечной системе от человека надо использовать гибкость. Человеку свойственно ошибаться, поэтому за пригнанностью компонентов друг к другу должна следить машина. Концепция СУБД, взятая мной за основу -- прекрасный пример гибкой и нерутинной работы с данными, которые нельзя охватить вручную.


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

А совсем в будущем, когда будет своя кодогенерация, для машинного кода вообще хочу сделать плавающее соглашение о вызовах -- аналог ASLR на уровне регистров. То есть на архитетурах с большим количеством регистров (x64, ARM) из неключевых регистров, используемых обычно россыпью, генерируются все возможные комбинации, обозначаемые цифрами или буквами. Программа компилируется не под единственную платформу x64, а под x64 тип 5, например. С другими типами она двоично несовместима.

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


В Delphi так и сделано. Да, неполноценно, не общесистемно, но все же лучше, чем ничего. Не оценили. А потом ушел в Microsoft и сделал системно.

Раз уж зашла речь о пакетах, думаю, не рассказать ли о проекции пространств имен на файлы и каталоги, то есть как файлы и каталоги исходников превращаются в пространства имен в среде Кантора. Тема выходит за рамки "Hello, world!", состоящего из одного файла, но закладывается в обратимый формат и будет реализовываться сразу после выхода первой альфы. Систему пространств я называю "как в играх" -- из игр ее взял.

_________________
Путь успеха Циолковского — правильно умереть