Как обрабатывать два сигнала в зависимости друг от друга?

Ответ 1

Зависимости циклов на языке реактивного программирования можно обрабатывать с помощью разнообразной семантики. Тот, который, по-видимому, выбран в scala.React - это синхронные реактивные языки и, в частности, Esterel. Вы можете хорошо объяснить эту семантику и ее альтернативы в статье "Синхронные языки спустя 12 лет" Бенвенисте А.; Caspi, P.; Эдвардс, С.А. Halbwachs, N.; Le Guernic, P.; de Simone, R. и доступны в http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1173191&tag=1 или http://virtualhost.cs.columbia.edu/~sedwards/papers/benveniste2003synchronous.pdf.

Ответ 2

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

Обратная связь и циклы - очень мощный механизм в потоке данных. Без них вы ограничены типами программ, которые вы можете создать. Взгляните на Flow-Based Programming - Loop-Type Networks.

Редактировать после второго сообщения pagoda_5b

Одно из заявлений в документе заставило меня обратить внимание...

Для правильно упорядоченных графов этот процесс монотонно переходит на более высокие уровни, обеспечивая тем самым данные согласованность, т.е. отсутствие глюков.

Мне сказано, что в рамках Scala.React не допускаются петли. Цикл между двумя узлами, казалось бы, заставляет систему постоянно пытаться поднять уровень обоих узлов навсегда.

Но это не значит, что вам нужно кодировать петли в рамках своей структуры. Возможно, у вас есть один путь от объекта, который вы хотите наблюдать, а затем еще один, отдельный путь к графическому интерфейсу.

Для меня всегда кажется, что слишком большое внимание уделяется программированию, завершающемуся и дающему один ответ. Петли затрудняют определение, когда нужно прекратить действие. Библиотеки, использующие термин "реактивный", склонны подписываться на этот мысленный процесс. Но это всего лишь результат архитектуры компьютеров Von Neumann... в центре внимания решения уравнения и возврата ответа. Библиотеки, которые уклоняются от циклов, похоже, беспокоятся о завершении программы.

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

Информационный поток не должен быть настолько сложным. Это совсем другой способ подумать о программировании. Я предлагаю вам посмотреть книгу Джона Пола Морисона "Flow Based Programming" для тестируемой версии потока данных или моя книга (как только это будет сделано).

Ответ 3

Ответ на @Matt Carkci здесь, потому что комментария не хватит

В разделе "7.1" "Изменение распространения" у вас есть

Наша реализация распространения изменений использует push-based подход, основанный на топологически упорядоченном графике зависимости. Когда начинается поворот распространения, пропагатор помещает все узлы, которые были недействительными с момента последнего перехода в очередь приоритет, которая сортируется в соответствии с топологическим порядком , на коротком уровне, узлы. Пропагатор деактивирует node на самом низком уровне и проверяет его, потенциально изменяя его состояние и помещая его зависимые узлы, которые находятся на больших уровнях, в очереди. Пропагатор повторяет этот шаг до тех пор, пока очередь не станет пустой, всегда отслеживая текущий уровень, что становится важным для несоответствий уровня ниже. Для корректно упорядоченных графов этот процесс монотонно переходит на более высокие уровни, обеспечивая тем самым согласованность данных, т.е. Отсутствие глюков.

а затем в разделе 7.6 Несоответствие уровня

Поэтому нам нужно подготовить непрозрачный node n для доступа к другому node, который находится на более высоком топологическом уровне. Каждый node, который считывается из оценки ns, сначала проверяет, превышает ли текущий уровень распространения, который поддерживается пропагатором, чем уровень node s. Если это так, то оно выполняется как обычно, иначе оно выдает исключение несоответствия уровня, содержащее ссылку на себя, которая попадает только в основной цикл распространения. Затем пропагатор поднимает n, сначала изменяя его уровень до уровня выше node, который выбрасывает исключение, повторно вставляя n в очередь распространения (поскольку его уровень изменился) для последующей оценки в том же самом повороте, а затем транзитивно поднимает все ns иждивенцы.

Пока нет упоминания о каком-либо топологическом ограничении (циклическом и ациклическом), что-то неясно. (по крайней мере для меня)

Сначала возникает вопрос о том, как определяется топологический порядок.

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

Как вы думаете?

Ответ 4

Проверьте MVC. Представление не обновляет модель, поэтому оно не будет посылать на нее сигналы. Контроллер обновляет модель. Для конвертера C/F у вас будет два контроллера (один для элемента управления F, для управления C). Оба контроллера будут посылать сигналы в одну модель (которая сохраняет только настоящую температуру, Kelvin, в формате без потерь). Модель посылает сигналы на два отдельных вида (один для просмотра C, один для просмотра F). Нет циклов.

Основываясь на ответе от @pagoda_5b, я бы сказал, что вам, вероятно, разрешено иметь циклы (7.6 должны обрабатывать его за счет производительности), но вы должны гарантировать, что нет бесконечного регресса. Например, вы могли бы заставить контроллеры также получать сигналы от модели, если вы гарантировали, что получение указанного сигнала никогда не приводило к отправке сигнала обратно в модель.

Я думаю, что приведенное выше является хорошим описанием, но оно использует слово "сигнал" в стиле, отличном от FRP. "Сигналы" в приведенном выше тексте - действительно сообщения. Если описание в 7.1 является правильным и полным, циклы в графике сигналов всегда будут приводить к бесконечному регрессу, так как обработка зависимостей node приведет к обработке node и наоборот, ad inf.

Как сказал @Matt Carkci, существуют рамки FRP, которые допускают циклы, по крайней мере, в ограниченной степени. Они будут либо не нажиматься, а использовать ненастроенность интересными способами, применять монотонность или вводить "искусственные" задержки, так что, когда диаграмма сигнала расширяется по временному измерению (превращая его в график значений), циклы исчезают.