Вычислитель Лиспекса и LIT

Топаз соприкасается с Лиспексом в двух местах, никак не связанных между собой. Первое из них — команда, вычисляющая одно правило на Лиспексе и сохраняющая результат в каталог. Для этого не требуется ни пакет, ни сборка. Второе — LIT, сокращение от Lispex-in-Topaz. Это интерпретатор Лиспекса, написанный на Топазе. Его используют как свидетельство проверок, а не как поставляемый продукт. Ни то ни другое не является бэкендом Топаза, и вместе они не делают Топаз и Лиспекс единым языком.

Что такое Лиспекс

Лиспекс — это небольшой Лисп для правил принятия решений, сознательно близкий к Scheme. Один вход даёт один детерминированный ответ. Одно и то же правило с одним и тем же входом всегда даёт один и тот же результат.

Запрос приходит списком именованных полей, и любой ответ, включая отказ, тоже возвращается списком. Это отдельный от Топаза язык со своей документацией и своей схемой версий. Подробности вы найдёте на сайте Лиспекс.

Какой путь выбрать

Чтобы встроить правила Лиспекса в собираемое приложение, перейдите в раздел Запуск правил Лиспекса.
Чтобы вычислить отдельное правило без пакета, используйте topaz lispex embed run.
Для выпуска приложения на Топазе выберите одну из поддерживаемых целевых платформ Топаза.
Чтобы понять назначение LIT, рассматривайте его как свидетельство совместной работы компонентов инструментария на крупной программе Лиспекса.
Чтобы использовать Лиспекс как самостоятельный продукт, обратитесь к его собственной документации. Здесь описана только интеграционная граница со стороны Топаза.

Выполните один ограниченный запрос

Подготовьте стандартный файл правила на Лиспексе, канонический входной файл lispex.embed-value/v1 и закрытый файл лимитов. Затем укажите новый каталог для результатов:

BASH

topaz lispex embed run \
  --source rule.lspx \
  --input value.lpxvalue \
  --limits limits.json \
  --output lispex-result

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

JSON

{
  "schema": "topaz.lispex-embed-limits/v1",
  "prepare": {
    "raw_source_bytes": 4096,
    "prepare_work": 1000000,
    "logical_allocation": 1000000,
    "syntax_depth": 64
  },
  "evaluate": {
    "canonical_input_bytes": 4096,
    "eval_work": 1000000,
    "logical_allocation": 1000000,
    "semantic_frames": 1000,
    "traversal_depth": 256,
    "output_bytes": 1000000,
    "diagnostic_bytes": 1000000,
    "transcript_bytes": 1000000,
    "transcript_events": 100,
    "result_bytes": 1000000
  }
}

При успешном выполнении каталог lispex-result содержит файлы result.lpxvalue и report.json. В случае детерминированной семантической ошибки или превышения лимита формируется только отчёт. При отклонении запроса или ошибке движка каталог не создаётся. Проверить конкретный компонент и политику без запасного варианта можно командой:

BASH

topaz lispex embed info --json

Команда не поддерживает выбор вычислителя, профиля, среды выполнения или маршрута. Она не ищет и не загружает компонент, не выполняет обратных вызовов Топаза и не переключается на LIT. Отчёт фиксирует выполнение и допуск продукта Топаза, но не является переносимым ядром квитанции в формате Лиспекса.

Что означают свидетельства LIT

Одна и та же эталонная версия исходного кода LIT исполняется напрямую, через сгенерированные программы на Rust и Python, а также в браузере. Эта комплексная программа позволяет выявлять дефекты проверки, генерации кода, среды выполнения и взаимодействия с окружением.

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

Граница продукта

Ограниченный вычислитель встроен в исполняемый файл Топаза, однако поддерживает только задокументированные компонент, профиль, входные файлы, лимиты и контракт результата. Он не является --target lispex, универсальным инструментарием Лиспекса или подтверждением эквивалентности языков.

LIT не входит в поставку Топаза и не является целевой платформой сборки. Параметр --target lit отсутствует. Проверки LIT не делают произвольную программу на Лиспексе поддерживаемым приложением на Топазе.

Использование Лиспекса в приложении на Топазе

Пакет позволяет связать именованные правила Лиспекса с конкретным ограниченным профилем, исходным кодом, лимитами и встроенным компонентом. Сборка с использованием lock-файла подготавливает каждое правило единоразово и формирует std.lispex вместе с std.lispex.rules. Код на Топазе работает с непрозрачными типами правил и значений, а не с необработанными дескрипторами Wasm. Подготовленные байты можно использовать для различных входных данных, однако память, глобальное состояние, счётчики и буфер транскрипта инициализируются заново при каждом вычислении. Лимиты вызова дополняются общими квотами приложения, механизмом отмены и обязательной очисткой.

Если достаточно типизированного результата, используйте evaluate. Для детерминированного результата с переносимой записью предназначена функция evaluateWithEvidence. Метод consumerArtifactBytes сохраняет запись, consumerArtifactFromBytes принимает её обратно только после проверки, а inspectConsumerArtifact и verifyConsumerArtifact возвращают стабильный идентификатор. portableCoreBytes извлекает точные байты ядра в формате Лиспекса при его наличии. freshReplay повторно вычисляет правило и входные данные с лимитами из записи в новом гостевом экземпляре, принимая только полностью совпавший артефакт.

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

Прикладной API поддерживается интерпретатором и текущим маршрутом генерации нативного продукта. На локальном нативном маршруте поддерживаемый пакет из двух модулей прошёл стандартную установку через npm, удаление исходного кода и компилятора, перенос исполняемого файла, обработку множества входных данных, обработку ошибок лимитов, восстановление после истечения таймаута, проверку свидетельства и повторный запуск. Маршруты Python, Web, HTTP-сервиса, хоста без полномочий и MCP с пустым набором компонентов отклоняют его до формирования результата. План развития отслеживает валидацию каждой поддерживаемой нативной целевой платформы для конкретного релиз-кандидата как следующую границу ограниченного продукта. Полный профиль использует отдельные компонент, профиль, контракт, проверку целей и допуск, не расширяя существующий вычислитель.