Liza Core: план развития

Цель Core — небольшой строгий язык для сложных алгоритмов без универсальных указателей. Системные возможности строятся поверх определённой семантики значений, вычислений и ошибок.

Уже реализовано

i8/i16/i32/i64, u8/u16/u32/u64, bool, контекстные литералы, неизменяемые привязки, функции, checked/wrapping-арифметика, сравнения, логические и побитовые операции, сдвиги, if/else, ранние возвраты и проверка типов. Работает нативная компиляция через собственный типизированный IR. Точные правила — в спецификации ядра.

1. Числовая модель — в работе

Целые типы, контекстные литералы, checked/wrapping-арифметика, логика с коротким замыканием, побитовые операции и сдвиги реализованы. Проверяются все ширины и граничные значения при O0/O2, включая trap, невыбранные ветви и входы, неизвестные компилятору. Первое применение — examples/rtp_fields.liza, выделение полей из двух уже переданных байтов заголовка.

Этап ещё не завершён: осталось определить синтаксис и реализовать явные преобразования и добавить насыщение. Деление и остаток реализованы для всех ширин, включая trap при нулевом делителе и MIN / -1, ноль для MIN % -1. Числовая модель различает реализацию и проекты; as и обозначение +| пока не утверждены.

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

2. Локальные вычисления

Локальные var, присваивание, while, for, break, continue. Изменение привязки не вводит идентичность объекта, изменяемые ссылки или разделяемое состояние. Контроль потока и обновление значений сохраняются в Liza IR независимо от размещения в регистрах или памяти.

Критерий: алгоритмы с накоплением результата, вложенными циклами, ранним выходом и пропуском итерации имеют определённое поведение на всех путях.

3. Составные значения

Сначала зафиксировать правила логического копирования, представлений и передачи владения, затем реализовать структуры, массивы, индексацию с проверкой границ и строки UTF-8. b = a для копируемого значения означает логическую копию, а не появление неявного пути изменения a.

Для больших буферов до реализации определить, где допустима копия, где нужен временный доступ и где передаётся владение. Подсчёт ссылок, copy-on-write или выделение памяти не должны возникать как неоговорённая стоимость привязки. Полная системная модель View остаётся этапом 6; контракт ограниченного доступа к входному буферу нужен уже здесь, до заявления о разборе без копий.

Критерий: разбор массива байтов с определёнными ошибками границ. Проверить логическую независимость значений, стоимость передачи больших массивов, валидность UTF-8 и единицы индексирования строк.

4. Алгебраические типы

Варианты, match, Option, Result, исчерпывающая проверка вариантов. Само создание варианта не требует скрытого выделения памяти; эффекты и стоимость его содержимого остаются явными.

Критерий: ошибки разбора представлены значениями, переходы конечного автомата обработаны исчерпывающе. Некорректные входные данные не требуют аварийного завершения процесса.

5. Модули и эффекты

Сначала импорт, экспорт, разрешение имён и границы модулей; отдельно — модель платформенных эффектов. Спроектировать контракты эффектов до добавления консольного и файлового I/O. Определить ошибки и освобождение ресурсов на успешном и ошибочном пути. Обязательного GC нет.

Критерий: чистое вычислительное ядро применимо без I/O; платформенный код явно сообщает свои эффекты и возвращает ошибки ресурсов.

6. Системная модель Liza — после Core

View, Handle, ownership, проверяемые эффекты, zero-copy и FFI. Проверка времени жизни, прав доступа, use-after-move, недействительных handles и стоимости совместного владения. Представление памяти в LLVM не определяет семантику этих сущностей.

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

Эталонные программы

Три сквозных примера: парсер RTP-заголовка, таблица соединений и конечный автомат узла кластера. Они развиваются вместе с языком и работают на тестовых данных без сети.

Первый содержательный критерий: можно ли выразить разбор RTP-пакета короче, чем сопоставимую безопасную реализацию на C, с проверкой границ и без дополнительных копий входного буфера? Это проверяемая гипотеза, не обещание. Полный критерий достигается после составных данных и контракта доступа к буферу, а не только после числовых типов.

Отложено

Классы, наследование, исключения, async/await, акторы, распределённые объекты и self-hosting не входят в ближайший Core. Планировщик, сеть, RTP fan-out, репликация и HA-сервис следуют после проверки базовой и системной моделей.