LINUX.ORG.RU

Data flow programming

 


1

3

Что-то мне приснилось на днях и подумал я запилить на коленке библиотеку для сабжа.

Основа системы - объект типа модель, который включает в себя ячейки с данными. Между ячейками есть связи, которые описываются наподобии:

(A, B, C) -> (X, Y)

и далее описывается код расчёта данных для ячеек в X и Y в зависимости от данных в ячейках A, B, С. При изменении данных отдельных ячеек в модели на основании вышеописаннх связей какие-то ячейки надо пересчитать, а какие-то нет (отображения функциональны). Называть этот процесс будем обновлением модели. Задача - определить данные каких именно ячеек нужно пересчитать и какой оптимальной последовательностью вычислений это сделать. Подобная задача решается такими программами как система сборки make и менеджерами пакетов. Здесь особенность в том, что основа ячейки - переменные в памяти программы.

Возникли следующие идеи:

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

У одного объекта типа модели может быть несколько представлений причём как разных типов так и схожих. Поэтому адрес на объект модели должен быть содержаться в составе объекта представления - без отношения наследования из ООП не смотря на привязанность типа представления к типу модели.

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

Может ещё есть алгоритмы совершеннее вышеописанных идей? Какие алгоритмы полезно изучить для реализации такого?

★★★★★
Ответ на: комментарий от anonymous

занятная штука этот ваш AbiWord.

вот судя по документу со страницы с скриншотами у него родной формат файла это XML.

который тривиально обрабатывается той же схемой, например в skribilo на guile достаточно реализовать свой reader (да и для xml там вроде уже есть generic reader)

дальше – больше. смотрю в pyabiword для привязок пистона к абиворду, и вижу там вот такое: pyabiword.defs – то есть, питоновые обвязки реализованы поверх схемных на guile.

вот интересно, а родные схемные хипстеры ещё оттудова не выкинули ли.

ну то есть: это же тоже клетки, связанные внутри

со всеми для литературного многомерного гипертекста втекающими и dataflow вытекающими.

anonymous
()
Ответ на: комментарий от anonymous

у тебя, кажется, тоже был проект какой-то интерактивной среды?

я не он, но сам-то что-нибудь пишешь?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.