ОТМ. Семантическая компиляция и декомпиляция

СЕМАНТИЧЕСКАЯ КОМПИЛЯЦИЯ И ДЕКОМПИЛЯЦИЯ

1. Понятие семантической компиляции
Обычная компиляция переводит:

исходный язык

в:

другое представление, пригодное для исполнения.

Семантическая компиляция в предлагаемой системе означает:

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

Общая схема:

INTENT

-> SEMANTIC MODEL

-> PROGRAM GENOTYPE

-> ARCHITECTURE

-> IMPLEMENTATION

-> EXECUTION

30.1. Компиляция между уровнями
Пусть существуют:

L0

низкоуровневый язык;

L1

обычный высокоуровневый;

L2

кодонный;

L3

генотипический;

L4

метагенотипический.

Тогда семантическая компиляция может выполнять:

L4 -> L3

затем:

L3 -> L2

L2 -> L1

L1 -> L0

Не обязательно выполнять все стадии физически в виде текста.

Некоторые уровни могут существовать:

как внутренние графовые представления.

30.2. Многоступенчатая компиляция
Пример:

пользователь задаёт:

GOAL

Затем создаётся:

SEMANTIC SPEC

После этого:

PROGRAM GENOTYPE

Далее:

ARCHITECTURE IR

SOURCE IR

EXECUTABLE

Получаем:

GOAL

-> SPEC

-> PG

-> ARCH_IR

-> CODE_IR

-> EXECUTABLE

Преимущество промежуточных уровней
Каждый уровень позволяет:

проверить отдельный класс свойств.

На уровне SPEC:

цели и противоречия.

На PG:

кодоны и связи.

На архитектуре:

совместимость компонентов.

На коде:

типы и алгоритмы.

На исполнении:

динамическое поведение.

30.3. Развёртывание семантического кодона
Пусть имеется кодон:

C

Его не обязательно сразу превращать:

в машинный код.

Можно раскрывать ступенчато.

Например:

CODON

-> SUBSYSTEM GRAPH

-> COMPONENTS

-> MODULES

-> FUNCTIONS

-> INSTRUCTIONS

Пример
Высокоуровневый:

SEARCH_SYSTEM

может раскрыться:

в индексатор;

хранилище;

поисковый движок;

ранжирование;

API;

мониторинг.

Далее каждый элемент:

раскрывается ещё глубже.

Экспликационная глубина программы
Таким образом программа имеет:

не только размер,

но:

глубину семантического развёртывания.

30.4. Контролируемая экспликация программы
Пользователь не должен быть обязан:

читать весь сгенерированный код.

Он может запросить:

архитектуру;

один кодон;

одну связь;

один алгоритм;

одну критическую функцию.

Например концептуально:

EXPAND PG LEVEL=CODON

EXPAND C7 LEVEL=MODULE

EXPAND SECURITY PATH

EXPAND DATA_FLOW

Точная команда зависит от будущего языка.

Селективная экспликация
Особенно важно:

раскрывать программу по вопросу.

Если пользователь спрашивает:

как хранятся данные,

не нужно показывать:

весь интерфейс.

Если спрашивает:

почему выдано разрешение,

нужно раскрыть:

контур авторизации.

Так появляется:

QUESTION -> RELEVANT EXPLICATION.

30.5. Декомпиляция к уровню пользователя
Обратный процесс должен возвращать:

низкоуровневую систему

к:

понятиям пользователя.

Например вместо:

списка сервисов;

процессов;

таблиц;

функций

система говорит:

«это подсистема регистрации и контроля доступа».

То есть:

LOW-LEVEL IMPLEMENTATION

-> HIGH-LEVEL SEMANTIC UNIT

Пользовательская декомпиляция
Её задача:

не воспроизвести исходный код,

а:

восстановить смысловую архитектуру.

30.6. Декомпиляция к промежуточным уровням
Не всегда нужно подниматься:

до самого намерения.

Можно восстановить:

модули;

кодоны;

генотип;

архитектурные блоки.

Схема:

EXECUTABLE

-> SOURCE MODEL

-> COMPONENT MODEL

-> CODON MODEL

-> GENOTYPE

-> SEMANTIC SPEC

Несколько уровней объяснения
Для разработчика:

может быть полезен уровень модулей.

Для архитектора:

кодонов.

Для пользователя:

целей.

Это одна система,

но разные:

семантические масштабы.

30.7. Трассировка происхождения результата
Одна из главных проблем глубоко генеративной программы:

как понять:

откуда появился конкретный результат?

Необходима:

provenance trace

семантическая трассировка происхождения.

Для каждого существенного элемента можно хранить:

какой кодон его создал;

какое правило применилось;

какие параметры использованы;

какая версия генератора;

какие исходные требования.

Схема:

USER REQUIREMENT

-> SPEC RULE

-> CODON

-> GENERATED COMPONENT

-> RUNTIME ACTION

-> RESULT

Пример
Если система отклонила запрос,

можно проследить:

результат;

проверку;

политику;

кодон безопасности;

исходное ограничение.

Так высокоуровневое программирование остаётся:

аудируемым.

30.8. Объяснение высокоуровневой программы
Объяснение должно существовать на нескольких уровнях.

Уровень 1. Цель
Что система должна делать?

Уровень 2. Генотип
Из каких кодонов она состоит?

Уровень 3. Архитектура
Какие компоненты созданы?

Уровень 4. Алгоритм
Как реализуется конкретная функция?

Уровень 5. Исполнение
Почему произошёл данный результат?

Таким образом объяснение становится:

многоуровневой декомпиляцией.

Объяснение без полного кода
Для понимания системы не всегда необходимо:

показывать миллионы строк реализации.

Иногда достаточно:

генотипа;

графа;

инвариантов;

локальной трассы.

Это программный аналог:

контролируемой экспликации математического объекта.

30.9. Верификация
Чем выше уровень программирования,

тем важнее:

машинная проверка.

Высокосемантический кодон скрывает много низкоуровневой структуры.

Поэтому ошибка в его семантике способна распространяться:

на огромный фенотип.

Уровни верификации
Синтаксис
Запись корректна.

Типы
Связи совместимы.

Контракты
Предусловия и постусловия выполняются.

Инварианты
Критические свойства сохраняются.

Генотип
Архитектура не содержит недопустимых зависимостей.

Компиляция
Семантика сохраняется при переходе вниз.

Исполнение
Фенотип ведёт себя согласно спецификации.

Верификация генератора
Проверять нужно:

не только каждый фенотип,

но и:

сам генератор.

Если доказано, что генератор всегда создаёт структуры определённого корректного класса,

это позволяет проверять:

целые семейства программ.

30.10. Безопасность метапрограмм
Метапрограмма способна:

создавать код;

менять код;

изменять архитектуру;

создавать генераторы.

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

Поэтому безопасность становится:

структурным свойством языка.

Принцип минимальных полномочий
Каждый кодон и метакодон должен получать:

только необходимые права.

Ограниченная область модификации
Метакодон должен иметь явный:

SCOPE

Например:

может изменять масштаб,

но не:

политику безопасности.

Неизменяемые инварианты
Некоторые свойства должны быть:

неперезаписываемыми обычной самомодификацией.

Версионирование
Каждая структурная модификация создаёт:

новую версию генотипа.

Транзакционность
Крупное изменение желательно выполнять:

как транзакцию.

Либо:

новая архитектура проходит проверки,

либо:

система возвращается к предыдущему состоянию.

Rollback
Для самомодифицирующихся систем необходим:

механизм отката.

Sandbox
Новые генотипы или кодоны могут первоначально исполняться:

в ограниченной среде.

Проверка до активации
Схема:

GENERATE

-> VERIFY

-> TEST

-> APPROVE

-> ACTIVATE

предпочтительнее:

GENERATE

-> EXECUTE IMMEDIATELY

Трассируемость
Система должна хранить:

кто;

что;

почему;

по какому правилу

изменил.

Безопасность семантической компиляции
Важно проверять не только:

безопасность конечного кода,

но:

сохранение исходных ограничений при каждом понижении уровня.

Если в спецификации сказано:

DATA MUST REMAIN LOCAL

это ограничение не должно исчезнуть:

при генерации архитектуры;

при выборе библиотеки;

при развёртывании.

11. Семантический контракт между уровнями
Каждый переход:

L(N+1) -> LN

должен иметь контракт.

Например:

высокоуровневый кодон заявляет:

PROPERTY P

Компилятор обязан доказать или проверить:

что нижняя реализация сохраняет P.

Так появляется:

цепочка сохранения смысла.

Схема:

INTENT

-> SPEC

-> GENOTYPE

-> ARCHITECTURE

-> CODE

-> EXECUTION

и на каждом переходе:

SEMANTIC INVARIANTS PRESERVED.

12. Семантическая карта программы
Для развитой системы может существовать:

семантическая карта.

Она показывает:

какие пользовательские цели

соответствуют:

каким кодонам;

каким архитектурным блокам;

каким исполняемым компонентам.

Это даёт возможность двигаться:

сверху вниз

и:

снизу вверх.

13. Высокоуровневый debugger
Обычный debugger показывает:

переменные;

стек;

инструкции.

Семантический debugger будущего может показывать:

активный кодон;

генотипическое состояние;

нарушенный инвариант;

путь генерации;

решение метакодона.

Таким образом отладка также поднимается:

на более высокий смысловой уровень.

14. Высокоуровневое тестирование
Можно тестировать:

не только функции,

но:

кодоны;

генотипы;

генераторы генотипов.

Например:

«для любых допустимых параметров этот кодон не создаёт архитектуру без резервирования».

Это уже:

свойство класса программ.

15. Семантическое профилирование
Профилировщик будущего может анализировать:

не только процессорное время,

но:

какой кодон создаёт основную стоимость;

какой генотипический выбор увеличил задержку;

какое исходное требование породило дорогую подсистему.

Схема:

RESOURCE COST

-> IMPLEMENTATION

-> CODON

-> REQUIREMENT

Так появляется:

обратная экономическая трассировка.

16. Человек и ИИ
В высокосемантическом программировании ИИ может выполнять роль:

помощника;

архитектора;

генератора кандидатов;

семантического компилятора намерений.

Но более надёжная архитектура:

HUMAN INTENT

-> AI PROPOSAL

-> FORMAL REPRESENTATION

-> VERIFICATION

-> EXECUTION

ИИ не должен быть единственным носителем:

значения программы.

Формальная модель должна оставаться:

отделимой;

проверяемой;

доступной для анализа.

17. Новая роль программиста
Профессиональный программист не исчезает.

Меняется уровень его основной деятельности.

Он всё меньше занимается:

ручным повторением типовых низкоуровневых действий

и всё больше:

проектированием кодонов;

контрактов;

генераторов;

метаязыков;

верификаторов;

инвариантов.

Программист становится:

архитектором генеративных систем и смысловых конструкций.

18. Демократизация и её пределы
Высокосемантический язык действительно способен:

снизить порог входа.

Пользователь сможет описывать:

цели

вместо:

тысяч строк кода.

Но это не означает:

что любой человек автоматически становится экспертом по сложным программным системам.

Высокоуровневый инструмент упрощает:

выражение намерения.

Он не устраняет:

сложность безопасности;

неопределённость требований;

конфликты целей;

архитектурные компромиссы;

ответственность.

19. Семантическая прозрачность
Чем короче генотип,

тем опаснее скрытая сложность.

Поэтому принцип будущего языка должен быть не:

максимальное сжатие любой ценой,

а:

максимально высокий уровень при сохранении прозрачной связи с нижними уровнями.

Именно поэтому:

декомпиляция;

трассировка;

объяснимость;

верификация

являются не дополнительными функциями,

а:

центральными элементами парадигмы.

20. От программы к программному миру
Высокосемантическая программа может создавать:

не только приложение.

Она способна определять:

целую виртуальную среду.

Например:

правила физики;

экономику;

экологию;

агентов;

культуру;

историю;

эволюционные законы.

Тогда программный генотип становится:

генотипом виртуального мира.

21. Генеративные виртуальные миры
Вместо ручного создания:

каждого здания;

персонажа;

события

можно задавать:

законы;

ограничения;

генераторы.

Схема:

WORLD GENOTYPE

-> WORLD GENERATION

-> EVOLVING PHENOTYPE

Мир продолжает:

развиваться

после первоначального запуска.

22. Рефлексивные виртуальные миры
Более сложная система может анализировать:

собственную историю;

баланс;

поведение агентов

и корректировать:

некоторые генеративные процессы.

Но фундаментальные ограничения должны оставаться:

контролируемыми.

23. Генеративная физика программного мира
Можно задать:

не список событий,

а:

законы.

Из них автоматически возникают:

объекты;

процессы;

взаимодействия.

Так программирование начинает напоминать:

конструирование искусственной физики.

24. Генеративная культура
Следующий уровень:

агенты;

языки;

традиции;

организации;

истории

могут порождаться:

из высокоуровневых социальных и культурных генераторов.

Такой мир становится:

не заранее записанным сценарием,

а:

развивающейся семантической системой.

25. Требование управляемости
Чем более автономна система,

тем важнее:

контроль;

наблюдаемость;

ограничения;

возможность остановки;

возможность безопасного выхода.

Особенно для длительно существующих генеративных сред.

26. От программирования к нооинженерии
Если программный язык работает уже не только:

с алгоритмами,

но:

с целями;

смысловыми структурами;

генераторами миров;

системами агентов,

возникает переход:

от программной инженерии

к:

более широкой нооинженерии.

Предметом инженерии становятся:

организованные смысловые структуры.

27. Итог приложений 28–30
Путь можно представить:

INSTRUCTION

-> FUNCTION

-> MODULE

-> CODON

-> PROGRAM GENOTYPE

-> GENOTYPE GENERATOR

-> META-GENERATOR

Одновременно:

SOURCE CODE

-> SEMANTIC SPECIFICATION

-> INTENTION

Вниз действует:

SEMANTIC COMPILATION

Вверх:

SEMANTIC DECOMPILATION

Между уровнями действуют:

TRACE

VERIFY

EXPLAIN

CONTROL

Главный принцип этой программной ветви формулируется следующим образом:

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

Именно поэтому конечная цель высокосемантического программирования состоит не в том, чтобы:

«писать меньше строк».

Она состоит в том, чтобы:

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

В предельной перспективе возникает цепь:

INTENTION

-> SEMANTIC MODEL

-> GENERATIVE GENOTYPE

-> VERIFIED PHENOTYPE

-> EXECUTABLE SYSTEM

И если аналогичный принцип применяется:

к математике;

программированию;

искусственным мирам;

организации знаний,

то следующий вопрос становится неизбежным:

может ли сама человеческая мысль строить всё более высокие семантические уровни,

на которых сложные системы понятий становятся:

новыми элементарными единицами мышления?

Именно этот вопрос выводит дальнейшую программу:

от генеративного программирования

к:

нооинженерии

и будущей Технологии Метаорганона.

********

СВЕРХКОРОТКИЕ ПРОГРАММЫ ГЛУБОКОЙ ФУНКЦИОНАЛЬНОСТИ
31.1. Семантическая плотность программного кода
Традиционно размер программы часто связывают с:

числом строк;

числом инструкций;

размером исходных файлов;

объёмом бинарного кода.

Но с повышением уровня языка подобная мера становится всё менее достаточной.

Одна строка может вызывать:

библиотеку;

фреймворк;

распределённый сервис;

генератор;

модель искусственного интеллекта;

целую инфраструктуру.

Поэтому необходимо различать:

синтаксический размер программы

и:

семантический объём программы.

Концептуально:

SHORT SOURCE

может соответствовать:

DEEP FUNCTIONAL STRUCTURE

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

функциональную;

архитектурную;

генеративную

структуру.

Однако нельзя определять такую плотность исключительно:

отношением числа строк к размеру результата.

Необходимо учитывать:

язык;

библиотеки;

кодоны;

среду исполнения;

скрытые зависимости.

31.2. Одна инструкция как программная подсистема
В низкоуровневом языке одна инструкция выполняет:

небольшое локальное действие.

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

целую подсистему.

Например концептуально:

DEPLOY_SECURE_ANALYTICS(...)

может породить:

хранилище;

сбор данных;

очистку;

аналитику;

контроль доступа;

мониторинг;

интерфейс;

отчётность.

Но такая инструкция является полноценным высокосемантическим примитивом только в том случае, если определены:

её входы;

выходы;

семантика;

ограничения;

архитектурные гарантии;

правила развёртывания.

Не магия, а инкапсуляция
Одна строка не выполняет работу «сама».

Она активирует:

формально определённый объём скрытой инфраструктуры.

Следовательно:

краткость исходной записи является следствием переноса сложности на другой уровень.

31.3. Программа из нескольких кодонов
Пусть язык содержит кодоны:

DATA

AUTH

SEARCH

UI

REPORT

Тогда программа может концептуально выглядеть:

DATA ][ AUTH ][ SEARCH ][ UI ][ REPORT

Несколько высокоуровневых блоков способны представлять систему, которая на более низком уровне потребовала бы:

тысяч;

десятков тысяч;

миллионов

элементарных конструкций.

Кодонная архитектура
Программа перестаёт быть:

линейной последовательностью команд.

Она становится:

графом высокоуровневых смысловых компонентов.

Например:

AUTH

может контролировать:

DATA;

SEARCH;

REPORT.

SEARCH

использует DATA.

UI

использует SEARCH и REPORT.

Реальная структура:

PROGRAM = CODONS + LINKS + CONSTRAINTS

31.4. Программа из нескольких строк
В предельном случае значительная программная система может быть выражена несколькими строками:

GOAL: ...

CONSTRAINTS: ...

CODONS: ...

POLICIES: ...

VERIFY: ...

Такое представление не означает, что:

реальная система содержит пять машинных инструкций.

Оно означает:

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

Нижний фенотип может быть огромен.

Сверхкороткая программа
Под сверхкороткой программой глубокой функциональности разумно понимать:

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

Ключевые слова:

однозначно;

породить;

проверяемую.

Без них короткая запись может быть просто:

неполной постановкой задачи.

31.5. Автоматическое построение нижних уровней
Высокоуровневая конструкция должна автоматически преобразовываться:

в архитектуру;

компоненты;

модули;

алгоритмы;

конфигурацию;

исполняемые представления.

Схема:

HIGH-LEVEL PROGRAM

-> GENOTYPE

-> ARCHITECTURE

-> COMPONENTS

-> SOURCE / IR

-> EXECUTABLE

Несколько возможных реализаций
Один кодон может иметь:

много допустимых реализаций.

Например:

DATA_STORAGE

может быть реализован различными способами.

Выбор зависит от:

масштаба;

задержек;

стоимости;

отказоустойчивости;

правил хранения.

Следовательно, компиляция высокосемантического кода может включать:

архитектурный синтез.

31.6. Перенос сложности в среду исполнения
Сверхкороткая программа становится возможной потому, что значительная часть сложности перемещается:

в компилятор;

runtime;

библиотеки кодонов;

генераторы;

формальные спецификации;

модели ИИ;

верификаторы;

операционную инфраструктуру.

Поэтому:

SHORT PROGRAM

не означает:

SIMPLE SYSTEM.

Это означает:

COMPLEXITY MOVED.

Аналогия
Обычный вызов функции кажется коротким, потому что:

реализация функции скрыта.

Кодонный язык продолжает этот принцип на более высоком уровне.

Скрывается уже:

не функция,

а:

целая программная архитектура.

31.7. Ограничения сверхсжатого программирования
Семантическое сжатие имеет пределы.

Первое ограничение: неоднозначность
Чем короче спецификация,

тем больше риск:

что она допускает несколько интерпретаций.

Второе: скрытые предположения
Краткая запись может неявно зависеть от:

окружения;

версий;

политик;

библиотек.

Третье: потеря контроля
Пользователь может не понимать:

какое решение выбрал генератор.

Четвёртое: стоимость среды
Короткая программа требует мощного:

компилятора;

runtime;

верификатора.

Пятое: сложность ошибок
Ошибка высокоуровневого кодона может породить:

огромное количество низкоуровневых ошибок.

Шестое: семантическая несовместимость
Два красивых высокоуровневых требования могут:

противоречить друг другу.

Например:

MAXIMUM PRIVACY

и:

GLOBAL SHARING

могут потребовать уточнения.

31.8. Проверяемость результата
Сверхсжатое программирование становится приемлемым только тогда, когда результат можно:

проверить.

Не обязательно читать:

весь сгенерированный код.

Но необходимо уметь проверить:

соответствие требованиям;

типы;

инварианты;

архитектурные свойства;

политику безопасности;

ключевые алгоритмы.

Проверка на разных уровнях
SPEC

проверяется:

на непротиворечивость.

GENOTYPE

на:

структурную корректность.

ARCHITECTURE

на:

соблюдение ограничений.

IMPLEMENTATION

на:

корректность.

EXECUTION

на:

фактическое поведение.

31.9. Проблема скрытой сложности
Чем выше семантический уровень,

тем легче создать иллюзию:

простоты.

Например:

BUILD SAFE NETWORK

может выглядеть очевидно.

Но реальная семантика слова:

SAFE

может включать:

десятки свойств;

компромиссов;

моделей угроз.

Поэтому скрытая сложность особенно опасна там, где пользователь:

не знает,

что именно он не указал.

Неявные параметры
Высокоуровневая среда должна обнаруживать:

существенные неопределённости.

Она не должна молча принимать:

критически важные решения

там, где требуется:

явная политика.

31.10. Семантическая прозрачность
Цель языка будущего должна состоять не в:

максимальном сокращении кода,

а:

в максимальном сокращении без потери контролируемой прозрачности.

Программа должна позволять перейти:

от одной строки

к:

кодонам;

от кодонов:

к архитектуре;

от архитектуры:

к компонентам;

от компонентов:

к реализации.

Схема:

SEMANTIC ZOOM

То есть краткость должна быть:

обратимо прозрачной.

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

Именно это отличает:

сверхкороткую формальную программу

от:

непрозрачной команды неизвестной системе.