Грамматическая машина. Том 26. GrammaLang: Практическое руководство.

text

hold tension_01

Идентификатор после hold — это существующий TensionNode. Оператор переводит его в статус held (если он ещё не в нём) и фиксирует.

Split — разделить контекст:

text

split {

// ветвь A

substance дух { energy: 0.9 }

} {

// ветвь B

substance материя { energy: 0.3 }

}

Каждая ветвь — это блок в фигурных скобках. Ветви выполняются в изолированных контекстах: изменения в одной ветви не видны в другой.

Resolve — разрешить противоречие:

text

resolve tension_01 with свобода

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

Grammar_change — сменить режим:

text

grammar_change polyphonic

grammar_change reactor

Допустимые значения: reactor (реакторный режим) и polyphonic (полифонический режим).

5.8. Полный пример скрипта

Вот скрипт на GrammaLang, анализирующий антиномию свободы и необходимости:

text

// Анализ антиномии чистого разума

substance свобода {

energy: 0.8

}

substance необходимость {

energy: 0.4

}

tension антиномия vs свобода vs необходимость reason "антиномия чистого разума"

modus разум полагает

modus разум мыслит

// Удерживаем противоречие в полифоническом режиме

grammar_change polyphonic

hold антиномия

// Затем переключаемся в реакторный и разрешаем

grammar_change reactor

resolve антиномия with свобода

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

5.9. Формальная грамматика (EBNF)

Полная грамматика языка в расширенной форме Бэкуса-Наура приведена в Приложении Б. Здесь — её упрощённая версия для понимания структуры:

text

program = { statement } ;

statement = substance_decl | modus_decl | boundary_decl

| tension_decl | operation ;

substance_decl = "substance" ID "{" "energy" ":" NUMBER "}" ;

modus_decl = "modus" ID ID ;

boundary_decl = "boundary" ID "{" "inside" ":" "[" { ID "," } "]"

"outside" ":" "[" { ID "," } "]" "}" ;

tension_decl = "tension" ID "vs" ID "reason" STRING ;

operation = hold_op | split_op | resolve_op | grammar_change_op ;

hold_op = "hold" ID ;

split_op = "split" "{" { statement } "}" "{" { statement } "}" ;

resolve_op = "resolve" ID "with" ID ;

grammar_change_op = "grammar_change" ("reactor" | "polyphonic") ;

5.10. Развитие синтаксиса

В версии 0.3 планируется полноценный парсер на Rust, который будет принимать скрипты GrammaLang из командной строки:

text

PS> grammalang run script.gl

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

Глава 5.11. ГМ-диагностика: когда машина ломается.

Грамматическая машина — это не магический прибор, который всегда выдаёт правильный результат. Это инженерная система, и, как любая система, она может давать сбои. Диагностика этих сбоев — не второстепенная задача, а неотъемлемая часть работы с ГМ. Без неё аналитик рискует принять ложную кристаллизацию за истину, а ложное замыкание — за разрешение.

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

5.11.1. Сбой Split: бесконечное ветвление.

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

Причина. Оператор split применён без критерия остановки. Агент или программист не определил, когда ветвление должно прекратиться. Это похоже на рекурсию без базового случая: каждое новое различие порождает следующее, и процесс уходит в бесконечность.

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

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

Исправление. Введите явный оператор collect или merge после split. Это не просто техническое действие — это онтологическое решение: мы заявляем, что ветви завершены и их результаты готовы к сборке. Если ветви принципиально не могут быть завершены (например, анализ бесконечного потока данных), используйте оператор throttle — ограничение количества ветвей или времени анализа.

5.11.2. Сбой Hold: вечное удержание.

Симптомы. TensionNode создаются, но никогда не разрешаются и не эскалируются. Онтологическая карта заполняется узлами напряжения, которые не влияют на дальнейший анализ. Агент или программа «застревает» в состоянии удержания, не переходя к следующим операторам.

Причина. Оператор hold применён без стратегии разрешения или эскалации. Это классическая ошибка, особенно в полифоническом режиме: аналитик или агент воспринимает «удержание» как разрешение ничего не делать. Но удержание — это активное действие: оно требует периодической проверки, не изменились ли условия, не появилась ли новая информация, которая позволяет разрешить противоречие.

Диагностика. Проверьте, задан ли у каждого TensionNode:

timeout — предельное время удержания;

escalate — условие, при котором удержание переходит в эскалацию;

review_interval — периодичность перепроверки условий.

Если ни одно из этих полей не задано — TensionNode «зависнет» навсегда. Если заданы, но не срабатывают — проверьте, не слишком ли жёсткие условия (никогда не наступают) или не слишком ли мягкие (срабатывают сразу, превращая удержание в разрешение).

Исправление. Для каждого TensionNode определите стратегию:

resolve_when — условие разрешения (например, поступление дополнительной информации);

escalate_after — время или событие, после которого узел передаётся на другой уровень;

periodic_review — регулярная проверка, не изменились ли условия.

В полифоническом режиме допустимо, чтобы некоторые TensionNode удерживались бесконечно — это философский выбор. Но этот выбор должен быть осознанным, а не случайным. Если вы удерживаете противоречие бесконечно, вы должны знать, почему, и это должно быть зафиксировано в reason.

5.11.3. Сбой Transition: потеря данных при подъёме.

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

Причина. Правило трансформации (via) не обеспечивает сохранение онтологической связности. Данные нижнего уровня переупаковываются в категории верхнего, но при этом часть информации отбрасывается как «несущественная». Ошибка в том, что критерий существенности определён неверно.

Диагностика. Проверьте цепочку происхождения каждой онтологической сущности. На онтологическом уровне каждая Substance должна иметь origin — ссылку на сущность или данные с нижнего уровня, из которых она была сконструирована. Если у Substance нет origin — это галлюцинация. Если origin есть, но не содержит всей необходимой информации — потеря данных.

Также проверьте, не нарушено ли правило соседства: переход возможен только между соседними уровнями. Если вы перешли с Lexical сразу на Ontological, минуя Syntactic, Semantic и Pragmatic, потеря данных неизбежна — потому что данные не были структурированы и интерпретированы на промежуточных уровнях.

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

text

transition Lexical to Syntactic via group_into_structures

then to Semantic via interpret_as_values

then to Pragmatic via contextualize_as_actions

then to Ontological via reformulate_as_entities;

Каждый переход сохраняет origin в Modus целевой сущности. На онтологическом уровне можно проследить всю цепочку: от сущности до исходных токенов.

Если потеря данных неизбежна (например, при анализе больших объёмов, где детали не помещаются в онтологическую карту), используйте оператор summarize — он создаёт резюме, но не теряет ссылку на исходные данные.

5.11.4. Сбой Grammar Change: режимный джиттер.

Симптомы. Система переключается между реакторным и полифоническим режимами слишком часто. Онтологическая карта меняет интерпретацию TensionNode каждые несколько тактов. Анализ становится нестабильным: вчера TensionNode был held, сегодня — resolved, завтра — снова held, без явной причины.

Причина. Критерии переключения (grammar_change when) определены слишком чувствительно. Любое微弱ное изменение контекста вызывает смену режима. Это особенно опасно, когда система автоматически переключается на основе эвристик, которые не были тщательно откалиброваны.

Диагностика. Проверьте историю переключений. В ресурсах MCP хранится GrammarChangeRecord для каждого переключения. Если переключения происходят чаще, чем раз в N тактов (где N — средняя длительность такта), это джиттер.

Также проверьте, не являются ли переключения циклическими: Reactor → Polyphonic → Reactor → Polyphonic без содержательных изменений в онтологической карте. Это явный признак того, что критерии переключения конфликтуют друг с другом.

Исправление. Введите гистерезис: для переключения из реакторного в полифонический требуется, чтобы критерий сохранялся в течение K тактов (например, 3). Для обратного переключения — аналогично. Это предотвращает дребезг.

Также добавьте явный критерий стабильности: grammar_change when (plasma_duration > 3_cycles) and (not switching_back_immediately). Это гарантирует, что режим меняется только после того, как система «убедится», что изменение действительно необходимо.

5.11.5. Композитные сбои: когда всё ломается вместе.

На практике сбои редко происходят поодиночке. Бесконечное ветвление (Split) приводит к перегрузке онтологической карты, что провоцирует вечное удержание (Hold). Потеря данных при переходе (Transition) создаёт галлюцинации на онтологическом уровне, которые вызывают ложные срабатывания Grammar Change. Возникает каскадный сбой.

Диагностика каскадного сбоя. Проверьте три индикатора:

Рост онтологической карты: если количество Substance и TensionNode растёт экспоненциально, а не линейно — это признак бесконечного ветвления.

Старение TensionNode: если средний возраст TensionNode (время с момента создания) превышает ожидаемый — это признак вечного удержания.

Частота переключений: если переключений больше, чем тактов анализа — это признак джиттера.

Если все три индикатора положительны, система находится в каскадном сбое.

Исправление. Остановите анализ. Зафиксируйте состояние онтологической карты как аварийный дамп. Выполните обратную трассировку: найдите последний корректный такт (где все три индикатора были в норме) и восстановите состояние до него. Затем перезапустите анализ с более строгими критериями остановки, разрешения и переключения.

5.11.6. Профилактика: иммунная система онтологии.

Лучший способ справиться со сбоями — не допускать их. Иммунная система онтологии, описанная в Главе 4.6, является профилактическим механизмом. Но её можно усилить тремя дополнительными практиками.

Практика 1: Регулярная ревизия TensionNode. Периодически (каждые N тактов) проверяйте все TensionNode. Для каждого узла задайте вопрос: «Это противоречие всё ещё актуально? Появилась ли новая информация, которая позволяет его разрешить? Не пора ли его эскалировать?» Ревизия — это оператор hold в действии: не пассивное ожидание, а активное удержание.

Практика 2: Аудит переходов. После каждого transition проверяйте, не потеряны ли данные. Сравнивайте количество сущностей на исходном и целевом уровнях. Если на целевом уровне сущностей значительно меньше, чем на исходном — возможно, вы потеряли информацию. Аудит — это оператор transition в действии: не просто переход, а переход с проверкой.

Практика 3: Мониторинг режимной стабильности. Ведите журнал переключений. Если переключений больше, чем тактов, или они образуют циклы, сигнализируйте об этом. Мониторинг — это оператор grammar_change в действии: не просто переключение, а переключение с осознанием.