October 25th, 2012

flow

Вопрос с подвохом

Вы читаете исходник приложения или датасета и видите указание координат в трёхмерном пространстве строчкой вида:
st.position 0.7 2.15 9.53
Что это?

На низком уровне можно перейти к особенностям выбранного языка/парадигмы и сказать:
1. Это применение функции.
2. Это применение конструктора алгебраического типа.
3. Это вызов метода.
4. Это посылка сообщения.
5. Это экспрессовский атрибут, XML-something, JSON-something, ...

Но что это на вашем, человеческом уровне?
Update:
А есть ли какой-то общий термин, которым вы можете охарактеризовать и эту строку, и следующую?
physical.weight 10.0
flow

Ситуации и модальности

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

На уровне разбора такую строку можно назвать сентенцией, s-expr'ом или кортежем. На уровне реализации в рамках какого-либо языка - сделать применением функции, вызовом метода, etc. Причём, от того, функция там или конструктор ADT, изменится код библиотеки, но не представление кода пользовательского.

Внутри какого-либо контекста предметной области - свойство, инструкция, характеристика, требование (список можно продолжать до бесконечности). Но нет единого термина, обозначающего всё это - свойство-или-инструкция-или-...

Для работы с этим набором смыслов на базовом уровне восприятия предлагается термин ситуация.

st.position 0.7 2.15 9.53 -- вы создаётся некую ситуацию.
case physical.weight w: add_weight_conditions w -- вы распознаёте ситуацию и создаёте другую ситуацию, в случае успеха.

Код функции, поля класса, инженерный проект - всё это наборы ситуаций.

Упоминание st.position позволяет понять, что у нас некая ситуация с позицией в трёхмерном пространстве. Но как нам её интерпретировать? Это мы бублик рисуем, ящик переставляем или геометрию детали для станка описываем? Это решает модальность.

Описание функции это модальность для ситуаций кода функции. Описание насоса это модальность для ситуации physical.weight 10.0.

case physical.weight w: add_weight_conditions w -- case physical.weight w является модальностью для add_weight_conditions w

Управляющие конструкции языка (if, while, ...), описания типов, пара glBegin/glEnd - всё это модальности для своего содержимого. Любая монада является модальностью (но сами модальности обычно непредставимы в виде монад). Версия датасета и версия приложения, с ним работающего, также являются модальностями.

Нельзя заранее предусмотреть все ситуации и модальности, которые понадобятся пользователю. И если простые ситуации можно протащить сквозь систему типов выбранного языка, то с модальностями сложнее. От этого возникают искажения. Например, код планируется в модальности "обработчик evt_interact GreenKey для Door101 в случае X", но пишется как именованное замыкание с последующей регистрацией, или ещё какая гадость с экземплярами анонимных классов. А если понадобятся сериализуемые coroutines, то привет закат солнца вручную.

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