Андрей Платов
Две недели пытался в муках родить Ярило. Хоть я и обещал себе сделать все проще, схематично, и “прототипично”, но руки не слушались. Выкинув несколько вариантов модели данных, я даже потратил несколько дней портируя на Nim замечательную реализацию языка Wren, от Bob Nystrom - мне показалось что Ярило хорошо ляжет на его модель, но, потратив эти дни, я почувствовал что опять двигаюсь в какую-то неправильную сторону.
В результате я возвращаюсь примерно к тому же, что уже имел прошедшим летом в качестве прообраза Ярило, но за эти две недели я родил одну важную мысль. Мысль кажется простой и с первого взгляда туповатой, но мне, по крайней мере в данный момент, она мне кажется важнейшей и ключевой: сборщика мусора не будет!.
Эта мысль у меня в голове расставила все на свои места. Чего я хочу? Я хочу делать Web-приложения, и под веб-приложениями я в первую очередь понимаю UI. Что такое UI? Это дерево. Дерево, блять! Де-ре-во, а дерево – это не граф. Какое замечательное свойство есть у дерева? В нем нет циклов, в нем (концептуально) на каждый элемент есть только одна ссылка.
Что такое state приложения в понимании большинства современных фреймворков? Это дерево. Его так и называют - дерево состояния. Что такое UI приложение - это преобразование одного дерева в другое. Грубо говоря это то, чем пытается заниматься React.js и его друзья. Этот фундаментальный взгляд на UI приложение я не буду оспаривать, я с ним согласен на 100%. Но я хочу большего
Мне нужен механизм (это может быть язык программирования) описания того как одни части дерева преобразуются в другие части. В моих фантазиях, такие преобразования могут зависить друг от друга. Например новая нода в дереве состояний порождает новую ноду в дом), а та, в свою очередь порождает еще одну ноду DOM (например с переводом текста, в случае если в некотором месте дерева состояния включена опция трансляции). И так далее.
Разницы между типами узлов дерева быть не должно. В том смысле что ноды состояния приложения, ноды описывающие DOM, или ноды хранящие трансиентные данные выглядят для приложения единообразно и я могу преобразовать что хочу во что хочу. Никто не мешает мне породить из UI некоторое состояние а потом его опять трансформировать в UI.
И самое важное: я не хочу задумываться о деталях. Состояние может быть огромным (по размеру), но я как пользователь должен иметь единообразый доступ к нему всему. Точно так же UI - я даже не должен знать что некоторая нода - это UI элемент. Я лишь хочу описать правила транформации и запустить приложение.
Сборка мусора и Linear Types
Итак, мысль о том что сборка мусора не нужна и что наше приложение – дерево, упорядочила все у меня в голове и несколько повлияло на дизайн языка. К сожалению, или к счастью, это не будет язык общего назначения. Концептуально – все данные храняться в дереве, и только в дереве. Это значит, что если нода A и нода B не может иметь общего ребенка C. Даже если С ноды B создается из C ноды A в процессе трансформации – то создасться копия C. Несомненно надо предусмотреть оптимизацию для immutable данных - в этом случае копия не имеет смысла, но опять же концептуально пользователь работает с деревом и только с деревом – копируются ли immutable данные под капотом или нет – не должно волновать пользователя.
Я конечно погуглил на тему этой деревянной идеи - ничего толком не нашел, кроме Linear Types - это не совсем мой случай, а более общий, когда на объект может существовать одна и только одна ссылка. По теме не так много статей, и в основном недоступная мне математика о Linear Logic, но есть очень интересные стайки от Henry Baker, например о Linear Lisp и стековых машинах в этом контексте Linear Logic and Permutation Stacks.
Этот путь (в Linear Logic) слишком умный для меня, я лишь буду руководствоваться правилом дерева. Технически, на ноду придется ссылаться не только из родительской ноды но и из обработчиков событий, процессов транформации, и так далее. Но еще раз: такие ссылки – это забота движка. Концептуально данные – дерево. Убили ноду – все, кирдык, если кто-то ее слушал и во что-то трансформировал, то и ему кирдык – трансформировался в ноль (хотя теоретически он может трансформировать “нулевую” ноду во что-то осмысленное).