Haskell Reactive-Banana FRP и цикл событий

Я все еще пытаюсь обернуть голову вокруг Haskell и FRP. В частности, я работал с некоторыми примерами, используя реактивно-банановый пакет и начинающий получать FRP.Haskell Reactive-Banana FRP и цикл событий

Однако я все еще не понимаю, как сеть событий знает, когда произошло событие ввода. Я понимаю, что в отличие от NodeJS, в которой цикл событий постоянно проверяется на вход пользователя, FRP использует другую структуру для «ожидания» или «проверки» пользовательских входов или внешних сигналов.

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

Я прочитал много работ Конала, Худака и др. и объяснения слишком технические. Просьба предоставить меньше технических объяснений.

Благодарим за помощь.

источник

2016-06-01 phage

Я думаю, что просто просто * обманывать * тех, кто их использует, используя * настоящее слово IO stuff * - например [this] (https://hackage.haskell.org/package/reactive-banana-sdl-0.2.0/ docs/src/Reactive-Banana-SDL.html # runSDLPump) использует таймеры SDL для накачки вовремя - из того, что, как я понимаю, вы используете похожие вещи (ваш обычный материал с обязательным/асинхронным/основанным на событии «IO'), чтобы построить свою основу (см. [здесь] (https://hackage.haskell.org/package/reactive-banana-1.1.0.1/docs/Reactive-Banana-Frameworks.html)) – Carsten

Я написал несколько примеров подключения FRP-библиотек к реальный мир. [Пример подключения реактивного банана к GLUT] (http://stackoverflow.com/questions/15129677/simpler-alternative-libs-to-reactive-haskell/26112094#26112094) демонстрирует стрельбу из _real world IO stuff_. [Пример подключения реактивного банана к блеску] (http://stackoverflow.com/a/20677522/414413) демонстрирует события шага в явном цикле событий, но с помощью обхода через IO для использования существующей поддержки в 'Reactive.Banana .Frameworks'. – Cirdec

Полезно иметь в виду различие между FRP, которая связана с созданием интересных Event сек и Behavior сек из основных, и платформы конкретных «клей код», который обеспечивает набор основных Event с, как и текущее положение мыши или нажатия клавиш.

В библиотеке Reactive-Banana это различие отражается в структуре модуля, Reactive.Banana.Combinators касается первой части, а Reactive.Banana.Frameworks касается второй части.

Теперь, понимая, как работает вторая часть (базовая Events), для понимания того, как работает первая часть (FRP); на самом деле, разные библиотеки могут делать очень разные варианты реализации.

Сообщалось, что в библиотеке Reactive-Banana сеть событий представляет собой огромную функцию обратного вызова, которая регистрируется в внешних источниках событий (так называемая AddHandler в библиотеке). Всякий раз, когда один из этих внешних источников вызывает функцию обратного вызова, последний пересекает график Event и Behavior в порядке зависимости, выполняет необходимые обновления для внутреннего состояния и, наконец, запускает действия, ранее зарегистрированные с reactimate.

Магия FRP заключается в том, что пользователь библиотеки не видит ни одной из этих деталей реализации, хотя иногда бывает полезно знать, что «event-сеть = огромная функция обратного вызова».

источник

2016-06-02 09:27:37

Спасибо Генриху за ответ. Я многому научился из вашей работы. Очень признателен. У меня есть следующий вопрос. Вы ссылаетесь на поток и взаимосвязь между событиями и поведением как сеть событий. Это то же самое, что график? – phage

@phage Да, они по сути означают одно и то же.Я делаю небольшое различие: я обычно использую «график» для обозначения событий, поведения и их соединений и «сети», чтобы ссылаться на это * вместе * с действиями IO и зарегистрированными обработчиками событий. Другими словами, я считаю, что первое было «чистым», а второе - «нечистым». Но это действительно просто небольшое различие в номенклатуре, которое я хотел бы сделать, чтобы добавить более высокую точность при написании об этом. –

Haskell Reactive-Banana FRP и цикл событий

ответ

Смежные вопросы