Манифест
TCSL

Число без единицы — не длина. 100 — это не 100 mm, а безразмерный скаляр. TCSL не позволяет складывать миллиметры с градусами, умножать объём на длину и получать несуществующую размерность L⁴. Система типов замкнута на диапазоне L⁰–L³ плюс отдельная ось углов, и эта замкнутость проверяется до того, как хоть один полигон будет построен.

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

Программа TCSL движется в одном направлении: от параметров к геометрии, от геометрии к экспорту. Зоны INPUT → LET → GEOMETRY → EXPORT следуют строго в этом порядке, и переход необратим. Это не ограничение выразительности — это архитектурное решение, отражающее реальный процесс проектирования.

INPUT — это то, что меняет заказчик. LET — это то, что вычисляет инженер. GEOMETRY — это то, что строит станок. EXPORT — это то, что считает калькулятор. Смешивать эти ответственности значит терять возможность автоматизировать каждую из них по отдельности.

Если параметр total_width изменился, все зависимые от него значения обновляются автоматически. В TCSL нет способа «забыть» обновить производный параметр, потому что производные параметры — это формулы, а не числа. let inner_width = total_width - 2 * board — это живая связь, не мёртвая запись.

Разделение на input (литералы, переопределяемые извне) и let (формулы, вычисляемые автоматически) гарантирует, что GUI-конфигуратор показывает ровно то, что нужно менять, и скрывает то, что менять нельзя.

TCSL — однострочный язык. Каждая инструкция занимает ровно одну строку. Продолжение строки не поддерживается. Конвейер |> — единственный способ выразить сложную операцию, и он остаётся на той же строке.

Это сознательная жертва компактности ради однозначности. Парсер синхронизируется по границе строки. LLM генерирует код построчно. Человек читает код построчно. Ошибка локализуется на одну строку. Диагностика указывает на одну строку.

Переменная в TCSL — это не просто адрес в памяти. Имя corpus_left_side описывает деталь для человека. Имя Bok_LDSP16mm_1 после export ... as описывает ту же деталь для калькулятора себестоимости. Оба имени живут в одной строке, и оба проверяются парсером.

TCSL связывает мир инженерного проектирования (читаемые имена переменных) с миром производственного учёта (кодифицированные имена деталей) через единственный синтаксический мост — конструкцию export ... as.

TCSL определяет 32 кода диагностики не потому, что язык сложен, а потому, что каждая ошибка заслуживает собственного объяснения. TCSL_E015 — не «type error», а «размерность результата выходит за диапазон L⁰–L³». TCSL_R008 — не «runtime error», а «деление на ноль». Каждый код — это адрес в спецификации, по которому можно найти объяснение, пример и способ исправления.

Парсер обязан обнаружить всё, что может обнаружить без запуска геометрического ядра. Две ошибки (R005 — пустой результат селектора, R006 — несовпадение типа при runtime-переопределении) остаются за парсером осознанно — они требуют выполнения. Всё остальное проверяется статически.

TCSL спроектирован так, чтобы его мог генерировать LLM пошагово, без возвратов. Четыре зоны соответствуют четырём фазам генерации: сначала базовые параметры (LLM извлекает из ТЗ), затем формулы (LLM вычисляет зависимости), затем геометрия (LLM строит детали), затем экспорт (LLM назначает имена для калькулятора).

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

Между генерацией кода и его исполнением стоит парсер. Он работает за миллисекунды, не требует FreeCAD, не потребляет GPU-токены и не создаёт файлов. Его единственная задача — сказать «да» или «нет, и вот почему».

Парсер проверяет всё, что можно проверить без геометрии: лексику, синтаксис, порядок зон, размерную алгебру, совместимость pipeline-типов, арность операций, уникальность экспортов, положительность параметров конструкторов, целочисленность счётчиков, деление на ноль. Это 30 проверок из 32 — парсер покрывает 94% спецификации.

Поведение парсера определяется спецификацией v1.5, а не реализацией. Если реализация расходится со спецификацией — это баг реализации, не спецификации. EBNF-грамматика v1.5 с 62 продукциями и 25 семантическими ограничениями — это формальный контракт, по которому можно написать альтернативную реализацию и получить идентичное поведение.

Парсер является reference implementation, но не эталоном. Эталон — текст спецификации. Парсер — его исполняемое воплощение.

TCSL v1.5 содержит 62 грамматических правила, 23 функции, 5 перечислений, 17 единиц измерения и 32 кода ошибок. Это немного. Это достаточно для описания корпусной мебели произвольной сложности. Каждый элемент языка должен оправдать своё существование задачей, которую невозможно решить без него.

Предложение о добавлении новой конструкции должно ответить на три вопроса: какую задачу невозможно решить существующими средствами, насколько это усложнит генерацию LLM и насколько это усложнит диагностику ошибок. Если ответ на любой из трёх вопросов неудовлетворителен — конструкция не добавляется.