Заходят как-то две машины Тьюринга в одну диаграмму… а у них имена одинаковые.

Я говорю «машины», а на деле — два разных экземпляра State @turing-machine-js/machine, сконструированные по-разному, с разным поведением во время исполнения, и со строго одинаковым state.name. Это происходило в библиотеке, которую я разрабатываю в качестве хобби с 2019 года, и я этого не замечал семь лет.

Обнаружил случайно, начиная с задачи на чистку Mermaid-визуализации. Закончил — кардинальной переделкой того, как композиция состояний отражается в имени. И узнал, что за этой переделкой прячется число .

Предположим, вы пишете интерпретатор машины Тьюринга, запущенный в Web Worker’е. UI должен показывать трейс — как машина шагает от состояния к состоянию, что пишется на ленту, как двигается каретка. Чтобы пользователь успевал считывать изменения в UI, между итерациями движка нужна короткая задержка — миллисекунды, регулярно, на каждом шаге. Это приостановка движка между итерациями — регулярная и предсказуемая, не «пауза» в смысле UI-кнопки «Пауза» (та останавливает машину до клика «Продолжить»).

Возникает вопрос: где именно в цикле итерации воркеру нужно реализовать приостановку? Кандидатов два, и выбор между ними фиксирует сразу два контракта: хуков движка и протокола между воркером и основным потоком. Выбрать точку — это спроектировать обе стороны сразу; промахнуться — испортить обе. Эта статья — про этот выбор.

Из трёх мажоров, описанных в предыдущей статье, два не всплыли в тестах. Они всплыли в двух дизайн-ревью, которые тесты провести не могут.

Когда «снисходительность к входным данным» становится ловушкой? Когда имя хука начинает диктовать потребителю модель мышления? Когда подстановка снимка состояния — это не приём, а сигнал, что фазы жизненного цикла стоят не на том такте? Три мажорных релиза одной библиотеки — про эти три вопроса.