Вопрос дизайна.
Вот есть "БД" на основе гиперграфа.
У нас в этой БД есть узлы с наборами (HList) атрибутов и гипердуги с ролями-концами. Роли требуют наличия определённых наборов атрибутов у включаемых узлов, например, роль "файл" гипердуги "первая строка файла" содержит требование, чтобы узел содержал атрибут "Имя файла" со строковым значением. У той же гипердуги вторая роль называется "первая строка файла" и требует, чтобы подсоединяемый узел имел атрибут "строка файла".
Как бы спроектировать язычок запросов?
Большую часть времени мы просто можем ходить по концам дуг: дай мне все узлы, стартующие из вот этого набора, которые можно получить, пройдя по таким концам дуг. Получается регулярное выражение, с альтернативами и прочим.
Примитив againstRole Role должен принять набор узлов, пройтись по всем их соединениям гипердугами и дополнить набор пройденных узлами, что соединены гипердугой с ролью-окончанием Role.
Оператор альтернативы (например, +++) позволит нам пройтись по нескольким ролям одновременно.
Оператор many выполнит навигацию по его аргументу до упора - пока будут узлы, что мы ещё не обошли.
Получится обход в ширину графа по определённым связям.
Если завести набор интересных узлов, то примитив interesting может добавлять текущее множество, полученное последней операцией навигации к множеству интересных. На него же можно навесить фильтр, как и на операцию againstRole (хотя тут роль не полностью определяет варианты атрибутов узла).
В конце мы можем получить как все пройдённые узлы, так и интересные нам.
По идее, на это можно будет навесить оптимизацию.
Второй вариант монадический. Мы сделаем монаду наподобие монады синтаксического разбора и получим возможность разбирать сложные синтаксические структуры внутри гиперграфа. Это тоже ценно - например, можно проверять ограничения на структуру наподобие соответствия типов в рисуемой схеме, чтобы система ругалась, если пытаются соединить землю и питание.
И даже можно сделать подсветку синтаксиса. ;)
Монадический вариант мне нравится больше. Надо его продумать. Здесь основной момент - как сделать обход вширь, но, возможно, недетерминированный, чтобы можно было обрабатывать узлы как независимо, так и с учётом соседей.
Подумаю.
У нас в этой БД есть узлы с наборами (HList) атрибутов и гипердуги с ролями-концами. Роли требуют наличия определённых наборов атрибутов у включаемых узлов, например, роль "файл" гипердуги "первая строка файла" содержит требование, чтобы узел содержал атрибут "Имя файла" со строковым значением. У той же гипердуги вторая роль называется "первая строка файла" и требует, чтобы подсоединяемый узел имел атрибут "строка файла".
Как бы спроектировать язычок запросов?
Большую часть времени мы просто можем ходить по концам дуг: дай мне все узлы, стартующие из вот этого набора, которые можно получить, пройдя по таким концам дуг. Получается регулярное выражение, с альтернативами и прочим.
Примитив againstRole Role должен принять набор узлов, пройтись по всем их соединениям гипердугами и дополнить набор пройденных узлами, что соединены гипердугой с ролью-окончанием Role.
Оператор альтернативы (например, +++) позволит нам пройтись по нескольким ролям одновременно.
Оператор many выполнит навигацию по его аргументу до упора - пока будут узлы, что мы ещё не обошли.
Получится обход в ширину графа по определённым связям.
Если завести набор интересных узлов, то примитив interesting может добавлять текущее множество, полученное последней операцией навигации к множеству интересных. На него же можно навесить фильтр, как и на операцию againstRole (хотя тут роль не полностью определяет варианты атрибутов узла).
В конце мы можем получить как все пройдённые узлы, так и интересные нам.
По идее, на это можно будет навесить оптимизацию.
Второй вариант монадический. Мы сделаем монаду наподобие монады синтаксического разбора и получим возможность разбирать сложные синтаксические структуры внутри гиперграфа. Это тоже ценно - например, можно проверять ограничения на структуру наподобие соответствия типов в рисуемой схеме, чтобы система ругалась, если пытаются соединить землю и питание.
И даже можно сделать подсветку синтаксиса. ;)
Монадический вариант мне нравится больше. Надо его продумать. Здесь основной момент - как сделать обход вширь, но, возможно, недетерминированный, чтобы можно было обрабатывать узлы как независимо, так и с учётом соседей.
Подумаю.