November 30th, 2012

flow

Скобочки

Последние месяцы в фоне скетчил различные ситуации в коде и данных, в текстовом и бинарном виде. Творческий, но чисто количественный процесс нахождения баланса, с получением максимума выразительности и минимума сложности восприятия.

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

В ситуациях res = (2+2)*3 или f (a*x+b) содержимое скобок себя идентифицирует. Введение промежуточных этапов вроде sum = 2+2; res = sum*3 не требуется.

В ситуации process_information_using (... полкило матана ...) (... запрос из базы, ад, коровники, джойны ...) получается write-only код в традициях APL. Длинный код в скобках просто не воспринимается. Для читаемости необходимы промежуточные модальности и идентификации.

При дизайне текстового представления это ведёт к такому решению: в каждой строке соблюдается баланс скобок, нельзя поставить открывающую скобку в одной строке, а закрывающую где-то в следующих. А совмещение крупных групп ситуаций с их модальностями (контекстами, уплавляющими конструкциями, см. http://justy-tylor.livejournal.com/191741.html) осуществляется не скобками, а индентацией.

modality1:
  situation1
  situation2
  modality2: situation3
  situation4
  situation5
  modality3:
    situation6
    ...

Индентация в 2 пробела, никаких табов, обязательный баланс скобок в пределах строки. Так максимизируется читаемость, и текстовое представление становится ближе к представлению в виде дерева, что особо удобно для описания данных. Добавим фолдинг лесенкой в редакторе и получится нормальное дерево, в котором можно просматривать и модифицировать инженерные датасеты приличного объёма.

В бинарном представлении (для контейнеров и протоколов) тоже есть свой вопрос скобок. А именно, позволять или не позволять указание каких-то выражений внутри бинарных ситуаций. Когда одним из аргументов ситуации является какой-нибудь vector3f, то такого вопроса нет - нам даже не нужен маркер типа vector3f, мы просто пишем три флота. Однако, если используются не только product types, но и sum types, то либо придётся создавать некий словарь констант, либо надо инлайнить данные прямо в ситуацию с использованием маркера типа, т.е. те же скобочки.

Кроме того, оба решения (словарь констант и скобки) немного усложняют парсинг, что и так необходимо для контейнера видеопотока или данных инженерного проекта, но плохо для микроконтроллеров. А придумывать разные правила для разных случаев не хочется, желательно обойтись разными словарями ситуаций.

Решение находится на уровне системы типов. Например, в словарике для микроконтроллера все ситуации (такие как "изменить значение регистра") идентифицируются одним байтом, регистры также идентифицируются байтами, булевы значения передаются как bool1, а sum types просто отсутствуют. Получается аналог Modbus.

А в словаре управляющей системы, которая с ним работает, идентификация "регистр 7 контроллера 3" уже мэппится на идентификацию boat.navigation_lights, которая при передаче инлайнится непосредственно по месту использования или упоминается ссылкой на словарь констант (смотря какие типы вы установите), а также имеет тип значения bool32. И именно в таком виде информация передаётся на навигационный компьютер яхты.

Один текстовый синтаксис, один бинарный протокол. Разные словари и типы. И сначала надо допиливать именно бинарную часть, систему типов, а текстовый сахар... с ним, в принципе, уже всё ясно.