Reactive Banana: использовать параметризованный вызов внешнего API

Фундаментальная проблема носит концептуальный характер: FRP-события и поведение можно комбинировать только в чистом виде. В принципе невозможно иметь функцию типа, скажем

mapIO' :: (a -> IO b) -> Event a -> Event b

потому что порядок, в котором должны выполняться соответствующие действия ввода-вывода, не определен.

На практике иногда может быть полезно выполнять ввод-вывод при объединении событий и поведения. Как указывает @ErikAllik, комбинатор execute может это сделать. В зависимости от характера getAnotherRemoteApiValue это может быть правильным решением, в частности, если эта функция является идемпотентной или выполняет быстрый поиск из местоположения в ОЗУ.

Однако, если вычисление более сложное, то, вероятно, лучше использовать reactimate для выполнения вычисления ввода-вывода. Используя newEvent для создания AddHandler, мы можем дать реализацию функции mapIO':

mapIO' :: (a -> IO b) -> Event a -> MomentIO (Event b)
mapIO' f e1 = do
    (e2, handler) <- newEvent
    reactimate $ (\a -> f a >>= handler) <$> e1
    return e2

Ключевое отличие от чистого комбинатора

fmap :: (a -> b) -> Event a -> Event b

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

Обратите внимание, что execute также гарантирует, что ввод и результат имеют одновременные появления, но накладывает неформальные ограничения на разрешенный ввод-вывод.

С помощью этого трюка объединения reactimate с newEvent аналогичный комбинатор может быть написан аналогичным образом для поведения. Имейте в виду, что набор инструментов из Reactive.Banana.Frameworks подходит только в том случае, если вы имеете дело с действиями ввода-вывода, точный порядок которых обязательно будет неопределенным.

(Чтобы этот ответ был актуальным, я использовал сигнатуры типов из готовящегося к выпуску реактивного банана 1.0. В версии 0.9 сигнатура типа для mapIO'

mapIO' :: Frameworks t => (a -> IO b) -> Event t a -> Moment t (Event t b)

)

TL;DR: прокрутите вниз до раздела ОТВЕТ:, чтобы найти решение и объяснение.

Прежде всего

getAnotherRemoteApiValue state = (`mod` 10) <$> randomIO + count state

недействителен (т.е. не проверяет тип) по причинам, совершенно не связанным с FRP или реактивным бананом: вы не можете добавить Int к IO Int — так же, как вы не можете напрямую применить mod 10 к IO Int, именно поэтому, в ответ на ваш первоначальный вопрос, я использовал <$> (это другое имя для fmap от Functor).

Я настоятельно рекомендую вам изучить и понять назначение/значение <$>, а также <*> и некоторых других методов классов типа Functor и Applicative — FRP (по крайней мере, так, как он разработан в реактивном банане) в значительной степени основан на функторах и аппликативах (и иногда Monads, Arrows и, возможно, какой-то другой более новый фундамент), поэтому, если вы не полностью их понимаете, вы никогда не станете опытным в FRP.

Во-вторых, я не понимаю, почему вы используете coreOfTheApp вместо sink output2 ... — значение coreOfTheApp связано с другим значением API.

В-третьих, как должно отображаться другое значение API? Или, точнее, когда он должен отображаться? Ваше первое значение API отображается при нажатии кнопки, но кнопки для второго нет. Хотите, чтобы та же кнопка вызывала вызов API и отображала обновление? Хотите еще одну кнопку? Или вы хотите, чтобы он опрашивался каждые n единиц времени и просто автоматически обновлялся в пользовательском интерфейсе?

Наконец, reactimate предназначен для преобразования действия Behavior в действие IO, а это не то, что вам нужно, потому что у вас уже есть помощник show и вам не нужно setText или что-то еще на статической метке. Другими словами, то, что вам нужно для второго значения API, такое же, как и раньше, за исключением того, что вам нужно передать что-то из состояния приложения вместе с запросом во внешний API, но помимо этой разницы, вы все равно можете просто продолжать показывать (другое) Значение API с использованием show как обычно.

ОТВЕТ:

Что касается того, как преобразовать getAnotherRemoteApiValue :: AppState -> IO RemoteValue в Event t Int, похожий на исходный remoteValueE:

Сначала я пытался пройти через IORefs и использовать changes+reactimate', но это быстро зашло в тупик (помимо того, что было некрасиво и чрезмерно сложно): output2 всегда обновлялся на один «цикл» FRP слишком поздно, поэтому это всегда была одна «версия». " позади в пользовательском интерфейсе.

Затем я с помощью Oliver Charles (ocharles) из #haskell-game на FreeNode обратился к execute:

execute :: Event t (FrameworksMoment a) -> Moment t (Event t a)

который я до сих пор еще не полностью понял, но он работает:

let x = fmap (\s -> FrameworksMoment $ liftIO $ getAnotherRemoteApiValue s)
             (appStateB <@ ebt)
remoteValue2E <- execute x

поэтому одна и та же кнопка будет вызывать оба действия. Но проблема с этим быстро оказалась такой же, как и с решением на основе IORef — поскольку одна и та же кнопка вызывала пару событий, а одно событие внутри этой пары зависело от другого, содержимое output2 все еще отставало на одну версию. .

Затем я понял, что события, связанные с output2, должны запускаться после любых событий, связанных с output1. Однако перейти с Behavior t a -> Event t a невозможно; другими словами, когда у вас есть поведение, вы не можете (легко?) получить из него событие (за исключением changes, но changes привязано к reactimate/reactimate', что здесь бесполезно).

Я, наконец, заметил, что по сути «выбрасываю» промежуточное значение Event в этой строке:

appStateB = accumB initialState $ transformState <$> remoteValue1E

заменив его на

appStateE = accumE initialState $ transformState <$> remoteValue1E
appStateB = stepper initialState -- there seems to be no way to eliminate the initialState duplication but that's fine

так что у меня все еще был точно такой же appStateB, который использовался как и раньше, но я мог также полагаться на appStateE для надежного запуска дальнейших событий, которые зависят от AppState:

let x = fmap (\s -> FrameworksMoment $ liftIO $ getAnotherRemoteApiValue s)
             appStateE
remoteValue2E <- execute x

Последняя строка sink output2 выглядит так:

sink output2 [text :== show <$> remoteValue2B] 

Весь код можно увидеть по адресу http://lpaste.net/142202, при этом вывод отладки по-прежнему включен.

Обратите внимание, что лямбда (\s -> FrameworkMoment $ liftIO $ getAnotherRemoteApiValue s) не может быть преобразована в бесточечный стиль по причинам, связанным с типами RankN. Мне сказали, что эта проблема исчезнет в reactive-banana 1.0, потому что не будет вспомогательного типа FrameworkMoment.