Ядро FTS на flang: вычислитель утилит

Третий слой из четырёх: по утилите и входной записи считает результат,
проверяет свойства и прогоняет примеры. 20 функций, все тотальные; рекурсии в
файле нет вовсе — правила, условия, свойства и примеры обходятся свёртками.

Семантика воспроизведена дословно, а не пересказана: проценты считаются как
(доля / 100) * значение, равенство скаляров по Object.is, свойство проверяется
после всех правил и при пустом списке правил тоже. Исключений в языке нет,
поэтому всё, что может отказать, возвращает сумму «Итог» с кодом и текстом
ядра; короткое замыкание условий выражено состоянием свёртки.

Совпадение с ядром на TypeScript доказано, а не заявлено: 20 документов,
24 утилиты, 11 180 входов, ноль расхождений — сверяются и значения, и коды
диагностик. Сетка входов выведена из моделей: значения примеров, константы
условий и границы c−1/c/c+1. Отдельным тестом проверено, что перевод
FtsScalar → «Скаляр» обратим, иначе сверка шла бы на подменённых данных.

Слой пришёл к тем же объявлениям типов, что и печать JSON, — контракт был
исправлен по ходу работы, и оба слоя теперь описывают «Скаляр» дословно
одинаково. Это условие стыковки: слои соединяются только через типы контракта.

Записаны 7 долгов, главный — executeUtility и сводка testUtilities: проверки
входа уровня документа требуют типа структуры, которого в контракте пока нет.
evaluateUtility, то есть то, что задаёт раздел 3, реализована полностью.

Author: the-homeless-god

flang/core/SPEC.md

@@ -248,3 +248,74 @@
    поэтому печать совпадает), но допускает то, чего объект JS допустить не
    может, — два одинаковых ключа. Проверки на это нет: значения приходят из
    объекта JS, где повтор невозможен по построению.
+
+### Вычислитель (`flang/core/evaluate.flang`)
+
+Тотальность: долгов нет. Все 20 функций файла помечены `тотальная` и доказаны
+`totality.mjs`. Рекурсии в файле нет вовсе: правила, свойства, условия и примеры
+— это списки, и обход каждого выражен свёрткой. Короткое замыкание `Array.every`
+(условия правила) и «первая диагностика прекращает счёт» (правила и свойства)
+выражены состоянием свёртки, а не выходом из цикла: сработавший отказ
+протаскивается дальше нетронутым, и тела остальных шагов не вычисляются.
+
+Дифференциальная сверка (раздел 5) на всех `.fts` репозитория: 20 документов,
+24 утилиты, 11 180 входов, ноль расхождений — совпадают и значения (по
+`Object.is`, до последнего бита), и коды диагностик. Проверка —
+`flang/test/core-evaluate.test.mjs`.
+
+Расхождения и отступления, оставленные сознательно:
+
+1. **Скаляр — сумма типов, а не строка.** То же отступление и по той же
+   причине, что долг 3 печати JSON: текстовый вид не различает `5`, `"5"` и
+   `да`, а `Object.is` их различает, и на этом различии стоит вся семантика
+   равенства. Поэтому `«Значение операнда»` несёт `«Скаляр»`, а объявления
+   типов раздела 2 в `evaluate.flang` и `json.flang` совпадают дословно —
+   вычислитель и печать обязаны читать одно значение. Первая версия файла шла
+   за буквой раздела 2 и разбирала текст сама (`parseScalar` ядра, включая
+   регулярное выражение числа, выраженное вычёркиванием цифр свёрткой по
+   десяти литералам); от этого пришлось отказаться, чтобы не заводить второй
+   разбор числа рядом с `Похоже на число` лексера. Раздел 2 стоит поправить.
+
+2. **`executeUtility` не реализована — только `evaluateUtility`.** Раздел 3
+   описывает семантику вычисления, и она воспроизведена полностью. Проверки
+   входа уровня документа (`FTS_UNKNOWN_UTILITY`, отсутствие объявленного поля
+   структуры, `FTS_UTILITY_INPUT_TYPE`, `FTS_UTILITY_INPUT_FIELD`) требуют
+   типа структуры и списка утилит, а «Утилита» раздела 2 знает только имя
+   своего входа (`принимает: строка`). Эти коды остаются за слоем, который
+   увидит «Документ» целиком; `FTS_UTILITY_INPUT` для поля, которого нет в
+   переданных привязках, здесь есть — его даёт `resolveField`.
+
+3. **Сводка `testUtilities` не реализована.** `FTS_NO_UTILITIES` и
+   `FTS_NO_UTILITY_EXAMPLES` — диагностики документа, а не утилиты, и по той же
+   причине им здесь не на что смотреть. Прогон примеров одной утилиты есть:
+   «Проверить примеры» возвращает список «Итог примера» — тот же набор полей,
+   что у `UtilityExampleResult` ядра.
+
+4. **Текст `FTS_EXAMPLE_MISMATCH` выбран здесь.** Кода `FTS_EXAMPLE_MISMATCH` в
+   ядре на TS нет вовсе: `testUtilities` возвращает `passed: false` без
+   диагностики, а код введён разделом 3 этого контракта. Сообщение —
+   `пример «X» утилиты «Y»: ожидалось A, получено B`, значения печатаются как
+   «к строке» (признак — `да`/`нет`, ничто — `ничто`). Дословного образца, с
+   которым это можно было бы сверить, не существует; если он появится,
+   поменять придётся одну строку.
+
+5. **Диагностика без `span`.** Формат ядра — `{ code, message, severity, span }`;
+   «Итог» несёт только код и сообщение. Позиции у вычислителя нет и взяться ей
+   неоткуда: он работает над «Документом», из которого разметка исходника уже
+   ушла. Слой, который печатает диагностику, обязан добавить `span` правила или
+   свойства сам.
+
+6. **Стандартная библиотека не переиспользована — нечего переиспользовать.**
+   После отказа от разбора текста (долг 1) в файле не осталось ни одного
+   действия над строками, кроме склейки сообщений встроенной «соединить»:
+   ни `Разбить по символу`, ни `Заменить` из `flang/stdlib/strings.flang` не
+   нужны. Импорта нет и по второй причине: `использует … из "…"`
+   (`flang/src/link.mjs`) появился одновременно с этим файлом, и завязывать
+   слой ядра на связывание, которое ещё меняется, рано.
+
+7. **Свойства не выражены постусловиями функции.** SPEC языка даёт
+   `postconditions` с полями `code` и `message`, и `compat.mjs` переводит
+   свойства FTS именно в них. Здесь так нельзя: утилита — это данные, а не
+   функция, её свойства известны во время вычисления, а не во время разбора
+   `evaluate.flang`. Постусловие пригодится генератору кода (утилита → функция),
+   а не вычислителю.