Среды выполнения и интерпретаторы

Три семейства

• Rust служит операционным эталоном языка с 205 из 205 отслеживаемых строк примитивных возможностей. Native, npm, открытый WebAssembly и Песочница представляют собой разные поставки одной реализации.
• LIL представляет собой интерпретатор, написанный на самом Лиспексе. Он поддерживает все 205 строк текущих примитивных возможностей.
• LIT представляет собой транслитерацию интерпретатора на Топаз. Она отдельно поддерживает 84 из 205 строк и отвергает 121. Независимость исходного кода не заявляется.

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

Требование языка и поддержка интерпретатора это разные вещи

Текущий контракт языка содержит 205 обязательных строк возможностей. Все они имеют нормативную пометку profile-required. Она описывает цель полного интерпретатора, а не выдаёт частичную реализацию за готовую.

Форматирование исходника это инструмент Native

lispex fmt, fmt --check и fmt --write доступны в Native CLI. Расширение VS Code/Open VSX передаёт Format Document установленному бинарнику. npm, открытый WebAssembly и Песочница форматирование не предоставляют, а расширение не скрывает отсутствие Native, тихо подставляя что-то другое. Форматтер меняет только пробельное окружение исходника. Это не другая программа, выполняющая правило, не семейство бэкенда, не семантический профиль и не источник evidence.

Native MCP это инструмент написания, а не бэкенд

lispex mcp serve предоставляет по локальному stdio текущий справочник профиля и реестра, ограниченный по размеру и времени авторский запуск доверенного исходника в том же эталонном Rust tree и точный каталог диагностики. Это не новый бэкенд и не sandbox для враждебного исходника, потому что текущий tree не считает всю гостевую работу и логические выделения, а тайм-аут или завершение worker не дают решения и переносимой квитанции. Сервер не принимает внешний маршрут, не выполняет поиск или запасной путь и существует только в Native. npm, открытый WebAssembly, браузер и Песочница MCP-сервер не предоставляют. Структурированный результат не может войти в Ваучер.

Core IR, байткод и семейство бэкенда это разные оси

Native может понизить весь текущий нормализованный профиль в lispex.core-ir/v1 в его единственной закреплённой форме, строго проверить эти байты и показать разрешённые ячейки, захваты, хвостовые позиции, requirements, координаты исходника и идентификаторы. Команды core-ir build, validate и inspect всегда указывают, что выполнение не производилось, а граница равна integrity-only.

Затем Native компилирует строгий Core IR в lispex.bytecode/v1 в его единственной закреплённой форме, проверяет бинарный артефакт до создания состояния и исполняет его в lispex-rust-vm/v1. VM непосредственно охватывает текущий профиль, то есть все 205 строк примитивов и 18 строк с вызовом гостевых процедур. Стандартным Rust-движком остаётся tree, а --engine vm выбирается явно и не имеет запасного пути.

Native macOS ARM64 может передать те же проверенные байты точному отдельно установленному lispex-topaz-vm/v1. У маршрута собственные reader, verifier и машина явного управления на Топазе. Допускается только фиксированный продукт Топаза 5.11 с закрытым контрактом запроса и результата, полным счётчиком u64, ограниченным размером полей транспорта и пятью нулевыми счётчиками запасных путей. Эти счётчики не ограничивают всю гостевую работу или логические выделения. compare-vms записывает обе VM, не делая Топаз стандартным движком или движком Ваучера.

В Native для macOS ARM64 можно также сгенерировать читаемый статический граф Топаза, скомпилировать его только точной установленной цепочкой Топаза 5.11 и установить закрытый AOT-продукт без исходников. aot inspect и validate ничего не выполняют, а aot run ничего не компилирует. Продукт, source map, артефакт, исполняемый файл, вход, полноразрядные ресурсы u64, наблюдения и пять нулевых счётчиков запасных путей связаны, и маршрут не входит ни в один живой шаг Ваучера.

compare-routes помещает эти явные маршруты в одну сводную проверку, не смешивая identity. Он один раз выводит исходник, Core IR и байткод, проверяет соответствие AOT, затем без повторов запускает tree, Rust VM, VM Топаза и AOT. Неперезаписываемая квитанция сравнивает семантику и только действительно сопоставимые ресурсы, а отсутствующие у tree счётчики остаются отсутствующими. Это локальная диагностика, а не новое семейство бэкенда или вход Ваучера.

Core IR остаётся невыполняемым материалом смысла, а проверенный байткод служит исполняемым артефактом VM. Tree и Rust VM разделяют значения и листья примитивов. Исходник VM Топаза структурно отделена, но собрана её же компилятором Rust Stage 0, поэтому линия VM указывается явно и не увеличивает молча число семейств исторической квитанции. Там остаются Rust, LIL и LIT. Meaning Graph остаётся отдельным путём проверяемого подмножества.

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

Явный выбор LIL или LIT строг, поэтому неподдерживаемая операция не передаётся скрыто в Rust или удобную функцию host. Поэтому частичные интерпретаторы полезны для проверки, но не маскируются под полные.

LIL сам выполняет всё семейство составных селекторов пар от caar до cddddr. Например, (caddr x) равнозначно (car (cdr (cdr x))). Композиция вычисляется внутри LIL, а не передаётся callback-функции host.

LIL также составляет abs, square, три предиката знака/нуля и типизированные boolean=? и symbol=? из уже допущенных числовых, сравнительных и типовых операций. Например, (abs -3/2) возвращает 3/2, а (boolean=? #t #t #f) возвращает #f. Проверка операндов и ошибки совпадают с эталоном Rust.

В текущем профиле конечных вещественных чисел complex?, rational? и real? сводятся к общему вопросу number? для любого значения. LIL также сам выполняет структурный !=, основанный на eqv поиск memv, структурный assoc и основанные на eqv assq/assv. Например, (memv 2 '(1 2 3)) возвращает хвост (2 3), а (assoc '(a b) '(((a b) . ok))) возвращает найденную пару.

LIL реализует char<?, char<=?, char>?, char>=? по Unicode scalar value, а string<?, string<=?, string>?, string>=? сравнивает лексикографически по этим значениям. Поэтому (char<? #\a #\b) и (string<? "a" "aa" "b") истинны. Это детерминированный порядок code point, а не locale collation, нормализация или сравнение без учёта регистра.

LIL также сам выполняет повседневную навигацию по агрегатам и преобразования. list-copy создаёт новый неглубокий каркас пар, list-ref и nth выбирают элемент, а list-tail возвращает хвост с общей структурой. make-list по умолчанию заполняет список значением 0, а make-string заполняет строку пробелом. Диапазоны string->vector и vector->string считаются в символах, а не в байтах, поэтому (vector->string (string->vector "aλ🙂")) возвращает тот же текст. Полученный вектор новый и изменяемый.

Операции регистра Unicode используют явно записанное ядро символов и строк host. Оно покрывает char-ci<? и остальные сравнения char-ci, char-lower-case?, char-upper-case?, char-whitespace?, char-upcase, char-downcase, char-foldcase, string-ci<? и остальные порядковые сравнения string-ci, string-upcase, string-downcase и string-foldcase. Преобразование символа применяет simple mapping и возвращает один символ, а строка использует full mapping и может изменить длину, например (string-upcase "Straße") даёт "STRASSE". Сравнение без учёта регистра сначала проверяет всю цепочку. В текущем профиле foldcase остаётся приближением через lowercase, simple для символов и full для строк, а не полной таблицей Unicode CaseFolding. Locale collation и нормализация не выполняются.

В LIL также доступны повседневные скалярные числовые операции. floor, ceiling и truncate округляют в указанном направлении, а round отправляет точную половину к ближайшему чётному целому. Exactness входа сохраняется, так что (floor 1.8) даёт 1.0, а (floor 9/5) даёт 1. exact и inexact->exact восстанавливают точное двоичное значение конечного inexact числа, поэтому (exact 0.5) даёт точное dyadic-значение 1/2, а не результат разбора десятичного текста. inexact и exact->inexact выполняют обратное преобразование. even? и odd? требуют целое. min и max точно сравнивают смешанные exact/inexact значения, при равенстве сохраняют первый операнд и возвращают inexact-результат, если хотя бы один вход был inexact. Проверка аргументов и свёртки min/max принадлежат LIL, а округление, преобразование exactness и чётность используют явно записанное числовое ядро host, а не скрытый запасной путь или независимую реализацию.

Семейство точных целочисленных операций не переводит смешанную пару целых в binary64 до вычисления результата. quotient/remainder усекают к нулю, а floor-quotient/floor-remainder округляют к минус бесконечности. Поэтому (remainder -7 3) даёт -1, а (modulo -7 3) даёт 2. truncate-quotient/truncate-remainder явно выбирают два компонента усечённого деления, а floor/ и truncate/ возвращают частное и остаток как два значения, поэтому (call-with-values (lambda () (floor/ -7 3)) list) даёт (-3 2). gcd и lcm остаются неотрицательными вариативными свёртками с единицами 0 и 1, и любой inexact-операнд делает итог inexact. expt разрешает только точный целый показатель, поэтому общее трансцендентное возведение в степень остаётся вне профиля. exact-integer-sqrt возвращает нижний корень и остаток как два точных значения. Деление и евклидовы свёртки написаны на Лиспексе, и только expt и exact-integer-sqrt используют объявленное расширенное числовое ядро host.

Процедуры высшего порядка для коллекций теперь полностью доступны в LIL. all? и any? используют строгий boolean и останавливаются сразу после ответа, а map, filter, reduce, fold-left и fold-right требуют ровно одно значение callback. for-each, string-for-each и vector-for-each отбрасывают любое число значений и возвращают ноль значений. string-map и vector-map сохраняют вид коллекции. Строки и векторы копируются до первого вызова. Каждый callback проходит через гостевой кадр продолжения, поэтому обработчики, одноразовые выходы и учёт ресурсов остаются в машине LIL, а не в callback среды.

Четыре процедуры вывода LIL, а именно display, write, newline и println, используют те же закреплённые гостевые renderer и частный приёмник вывода с фиксированными пределами. Явный вывод и автопечать CLI сохраняют общий порядок stdout, но проекция корневых значений записывается отдельно, поэтому произвольный текст display нельзя принять за результат. Вывод не попадает в stdout host, а последующая ошибка не стирает уже записанные байты.

Три устаревающих совместимых имени реализованы без расширения профиля. % передаёт работу modulo, а list-first и list-rest передают работу car и cdr. LIL записывает W330/W331 так же, как Rust, то есть один раз на место вызова, в порядке первого появления. Перекрытое имя не предупреждает, а предупреждение сохраняется и при последующей ошибке предпочтительной операции. Этот упорядоченный канал отделён от stdout, значений и диагностики ошибки.

Что обязан объявить исполнитель

Общая историческая квитанция связывает каждый из 144 случаев с выполненным продуктом Rust, LIL и LIT, его пределами, наблюдениями и происхождением. Она не допускает неизвестного исполнителя автоматически.

Возможности продукта не равны

Native предоставляет полный путь Ваучера, а именно идентификаторы, политику, выдачу, аутентификацию, повторное выполнение, локальную проверку допуска и явное согласие VM с артефактом из точного исходника. npm использует общий Rust для идентификаторов, политики и аутентификации, но не читает скомпилированный артефакт, не выдаёт и не применяет решение. WebAssembly и Песочница выполняют Лиспекс и работают с точными изображениями без инструментов доверия Ваучера.

Native может получить точную VM Топаза для macOS ARM64, названную встроенным официальным каталогом, либо установить отдельно переданный точный локальный companion из каталога, закреплённого до байта, и stored-ZIP. Получение отделено от исполнения и не создаёт новое семейство, новую target, discovery, default, запасной путь, сетевое исполнение или полномочия Ваучера.

Частая ошибка

Сгенерированный Rust, Python, веб-маршрут или другая упаковка одного исходника не становится новой реализацией. Четыре маршрута LIT могут подтвердить согласие поставки в своей области измерения, но не являются четырьмя свидетелями.

Куда дальше

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

Байткод и Rust VM · Матрица наблюдений · Выбор способа запуска