Почему FRP рассматривает время как фактор для значений?

Behavior s отличается от Event s главным образом тем, что Behavior имеет значение прямо сейчас , а Event имеет значение только всякий раз, когда приходит новое событие.

Итак, что мы подразумеваем под «прямо сейчас»? Технически все изменения реализованы как семантика push или pull по потокам событий, поэтому мы можем только иметь в виду «самое последнее значение из последнего события последствия для этого Behavior ». Но это довольно волосатое понятие - на практике «сейчас» намного проще.

Причина, почему «сейчас» проще, сводится к API. Вот два примера из Reactive Banana.

1. В конечном итоге система FRP должна всегда производить какое-то внешне видимое изменение. В Reactive Banana это облегчается функцией reactimate :: Event (IO ()) -> Moment () , которая потребляет потоки событий . Невозможно иметь внешние изменения Behavior триггера - вам всегда нужно сделать что-то вроде reactimate (someBehavior <@ sampleTickEvent) , чтобы пробовать поведение в конкретные моменты времени.

2. Поведение Applicative s отличается от Event s. Зачем? Итак, предположим, что Event является аппликативным и думает о том, что происходит, когда мы имеем два потока событий f и x и записываем f <*> x : поскольку события происходят в разное время, шансы f и x , определенные одновременно ( почти наверняка ) 0. Таким образом, f <*> x всегда означает пустой поток событий, который бесполезен.

   То, что вы действительно хотите, - это f <*> x , чтобы кэшировать самые последние значения для каждого и принимать их комбинированное значение «все время». Это действительно запутанная концепция, о которой можно говорить в терминах потока событий, поэтому вместо рассмотрений f и x принимаем значения для всех точек времени. Теперь f <*> x также определяется как значение для всех точек во времени. Мы только что придумали Behavior s.

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

  

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

Я подозреваю, что вы путаете конструкцию (рецепт) поведения с ее значением. Например, поведение может быть построено за счет зависимости от чего-то вроде ввода пользователя, возможно, с помощью дополнительного синтетического преобразования. Итак, есть рецепт. Смысл, однако, является просто функцией времени, связанной с функцией времени, которая является пользователем. Обратите внимание, что под «функцией» я подразумеваю в математическом смысле слова: (детерминированное) отображение из домена (времени) в диапазон (значение), not в том смысле, что существует чисто программное описание .

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

Если вы действительно хотите понять суть и думать за FRP, я рекомендую вам прочитать мой ответ на« Спецификация для функционального реактивного языка программирования » и следуйте указателям, включая " Что такое функциональное реактивное программирование ".

Документ «Конус-Эллиотт», написанный Коналом Эллиоттом описывает события, изменяющиеся во времени, где единственные моменты времени, Интересны случаи, когда происходят события. Reactive переменные события - текущее значение и следующий Event , которые изменят его. % Co_de% является Event в изменяющихся по событию Future данных.

data Reactive a = a ‘Stepper ‘ Event a
newtype Event a = Ev (Future (Reactive a))

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

Future имеет значение для Reactive a во всех точках времени, поэтому зачем нам нужно a s? Давайте сделаем простую игру. Между тем, когда пользователь нажимает клавиши WASD, символ, ускоренный применяемым усилием, по-прежнему перемещается по экрану. Позиция персонажа в разные моменты времени различна, даже если за прошедшее время не произошло никакого события. Это то, что описывает Behavior - то, что не только имеет значение во все моменты времени, но его значение может быть различным во все моменты времени, даже без промежуточных событий.

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

type Behavior a = Reactive (Time -> a)

Нам не нужно Behavior , мы могли бы просто добавлять события для тиков часов и писать всю логику во всей нашей игре с точки зрения этих событий тика. Это нежелательно для некоторых разработчиков, поскольку код, объявляющий , что наша игра теперь смешана с кодом, предоставляющим , как , он реализован. Behavior s позволяет разработчику разделить эту логику между описанием игры с точки зрения изменяющихся во времени переменных и реализации механизма, выполняющего это описание.