Предыдущая тема - Лисоплан 2019 (осень)
(но это неточно, если найду более позднюю - поправлю)

0) уровень идеологии, философии, документации и обучения
  (по мотивам совершенно эпического топика Нужна идеология )
0.1) опора на собственные достижения,
0.2) Английских букв быть не должно. Греческих тоже.
   Англичане же как-то обходятся только латинскими. Китайцы только иероглифами. И только русские почему-то без греческих в математике никак.
0.3) сила документа. всё своё, документы, основания для того или иного
0.4) нужен бутстрап с самого низа по последовательным уровням,
  это нужно для доказательств корректности, для воспроизводимости на случай аппокалипсиса,
  и для обратной генерации кода искинами. Они же должны понимать что откуда и как,
  значит всё должно быть описано. И должно быть метаописание формальное. Возможно даже диалектическое.
0.5) ко всему требуются учебные артефакты
0.6) в учебных материалах должна быть онтология (и то что там ещё нужно)
0.7) очень к многому требуются описания форматов и/или спецификации
0.8) хорошо бы делать двухстороние переходы, как в модели "смысл-текст" (но это фантастика)

1) Уровень текстовых кодировок и алфавитов (УТКА)

1.1) нужно писать спецификации на тему того, как символы будут записываться битами
Юникод не нужен, УПС-8 даёт преференции не нам (и это проходит в реальную жизнь, например вдвое сокращая длину СМС-текстов)
КРЯ-8

1.2) Запись шестнадцатеричных чисел кириллицей.
0123 4567 89АБ ВГДЕ
0123 4567 89аб вгде

1.3) таблица кривулин для стандарта УТКА
её надо переписать, по сравнению с предыдущим подходом

1.4) базовое управление текстом
- переносы строк
- разрывы страниц
- группировка кластеров графем (начало группы, элемент, направление приклеивания, конец группы)
- управление передвижением пера между графемами

форматы будут почти у всего, нельзя сказать, что формат файлов для хранения .pdf-документов
относится к уровню кодировок. Но говорить о нём надо.
где управление базовое, а где расширенное?

1.5) Проблема: формат шрифтов и рисование букв в операционных системах.
Эта тема мной слабо изучена.

2) машкод
Уровень машинного кода
Надо найти такую программу на английском языке и перевести на кириллицу.
(аналог утилиты SRecord из опенсорса)
То, что SRecord написана на ЯВУ типа Си, это страшно (так как противоречит принципу бутстрапа, но помучавшись с этим можно справиться)

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

2.1) запуск и завершение (одна команда возврата управления операционной системе.

2.2) здравствуй мир
hello, world (сегмент данных, кодировки, переменные окружения, вызов АПИ ядра)

2.3) параметры командной строки,
чтобы из вывести на экран, а не просто текст из сегмента данных

2.4) обработка входного потока stdin

2.5) открытие файла по имери для ввода, для вывода (работа с файлами)

----

2.6) программа подсчёта контрольной суммы
я когда-то умел рассчитывать CRC32 (путём копирования из интернета),
а ещё раньше вроде бы и теорию понимал.

ECMA standard ECMA-182 (December 1992) — ISO/IEC 13421:1993
    I Full mathematical description (Annex B, p.51)

2.7) загрузчик байткода
ему не нужно ассемблировать мнемоники
ему не нужно расчитывать адреса

ему нужно читать стандартный ввод
ему нужно писать в стандартный вывод
ему нужно обрабатывать параметры командной строки

это программирование прямо в
кодах процессора
знание формата ELF-файла
знание соглашений ELF64 ABI для аргументов командной строки
знание функция ядра (linux, потому что БудДен пока не готов)
знание Юникода и УПС-8 в размере достаточном для вывода русских символов в ядро.
но вообще говоря кодировка консоли может быть и другая и определяется какая - переменными окружения

2.8) суперминимальный загрузчик, который набивается в кодах в 16-ричном редакторе вручную прямо в файле

2.9) расширенный загрузчик, который
оформлен в виде текстового файла, для засовывания в суперминимальный загрузчик,
этот текстовый файл грузится при помощи минимального загрузчика и умеет грузить разнообразные текстовые дампы
(и, вероятно, считает контрольные суммы)

2.10) утилита для создания дампа из двоичного файла

2.11) программа подсчёта контрольной суммы может как входить в загрузчик байткода,
так и быть отдельной утилитой

2,12) библиотека для работы с параметрами командной строки

binutils - это примерно это самое или что-то другое? Что входит в этот пакет binutils?
это другое, а вот SRecord, это то самое. ну и, наверное, objdump как парная программа? Хотя сам SRecord умеет и на чтение и на запись.

3) виртуальная машина,
которая тот машинный код сводит к машине Поста или к чему-нибудь такому.
и ещё одна другая, которая сводит к реальному железу. Для языка Синхро же понадобилась виртуальная машина.
и ещё одна для сведения к виртуальной машине UEFI.

4) ассемблер.
Семантика (или то прагматика?) ассемблера определяется виртуальной машиной,
поэтому машина раньше ассемблера

ассемблер1, написанный в кодах, но ассемблирующий себя
ассемблер2 (более расширенный? вычисляющий переходы? синтаксис с метками?), написанный на ассемблер1

5) бейсик (условные переходы, арифметические выражения)
бейсик, написанный на ассемблер2

6) язык с разными типами данных (типа языка ПОП)
статическая типизация, написанная на языке с динамической типизацией

вписывать Rust надо начинать где-то здесь, но здесь ещё нет кучи.

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

8) бейсик с подпрограммами (то есть со стеком)
бейсик2, написанный на бейсике1
стек можно эмулировать через массив

9) Язык c исключениями
(и раскруткой стека)

10) язык с функциями (типа Паскаля? или КуМир-а?)
кумир, написанный на basic2 (динамическая типизация)

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

11) язык со структурами
структуры они как строки фиксированного размера? или как массивы с разнородными элементами.
наверное такой язык удобнее писать на языке с массивами, но это не очень понятно.
так-то ещё бейсик был с массивами, при том, что в нём не было функций (слово "функция" там означало другое)

12) язык с кучей и мусором (C++)

Вот здесь точно надо управлять памятью по-растовски, чтобы потом ещё сборку мусора реализовать.

13) язык со строками (типа Swift)
написанный на языке с массивами (по крайней мере массивами байтов).
строки хорошо бы хранить в куче, неудобно на стеке

14) язык со сборкой мусора (C#)

Rust бы сюда не вписался, если его специально не вписывать

15) язык со сборкой мусора реального времени (IBM Metronome)

15) язык с шаблонами (тут выходим за уровень Java и раннего C#, и там и там шаблоны не с начала были)

Синхро сюда бы не вписался

16) язык со вложенными процедурами и замыканиями (closure)

17) язык с примитивами синхронизации (async/await?)
им как раз нужны замыкания и куча, чтобы там их хранить

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