Что такое (функциональное) реактивное программирование?

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

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

Основная идея реактивного программирования заключается в том, что существуют определенные типы данных, которые представляют значение «с течением времени». Вычисления, которые включают эти изменяющиеся во времени значения, сами будут иметь значения, которые изменяются во времени.

Например, вы можете представить координаты мыши как пару целочисленных значений во времени. Допустим, у нас было что-то вроде (это псевдокод):

x = <mouse-x>;
y = <mouse-y>;

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

Если мы затем сделаем некоторые вычисления на основе этого, результирующие значения также будут значениями, которые меняются со временем. Например:

minX = x - 16;
minY = y - 16;
maxX = x + 16;
maxY = y + 16;

В этом примере minX всегда будет на 16 меньше, чем координата x указателя мыши. С реактивно-ориентированными библиотеками вы могли бы сказать что-то вроде:

rectangle(minX, minY, maxX, maxY)

Окно размером 32x32 будет нарисовано вокруг указателя мыши и будет отслеживать его, куда бы он ни двигался.

Вот довольно хорошая статья по функциональному реактивному программированию < / а>.

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

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

Для меня это примерно два разных значения символа =:

1. В математике x = sin(t) означает, что x - это другое имя для sin(t). Так что писать x + y - это то же самое, что и sin(t) + y. Функциональное реактивное программирование похоже на математику в этом отношении: если вы напишете x + y, оно будет вычислено с любым значением t в момент его использования.
2. В языках программирования C-подобных (императивные языки) x = sin(t) - это присвоение: это означает, что x хранит значение sin(t), полученное во время присвоения.

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

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

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

Чтобы узнать больше о «вычислениях потока данных», поищите эти два слова в Википедии или в своей любимой поисковой системе. Общая идея такова: программа представляет собой ориентированный граф узлов, каждый из которых выполняет простое вычисление. Эти узлы связаны друг с другом связями графа, которые предоставляют выходы одних узлов входам других.

Когда узел запускается или выполняет свои вычисления, соответствующие входы узлов, подключенных к его выходам, «срабатывают» или «отмечаются». Любой узел, у которого все входы активированы / отмечены / доступны, автоматически срабатывает. График может быть неявным или явным, в зависимости от того, как именно реализовано реактивное программирование.

Узлы можно рассматривать как запускаемые параллельно, но часто они выполняются последовательно или с ограниченным параллелизмом (например, их может выполнять несколько потоков). Известным примером является Manchester Dataflow Machine, который (IIRC) использовал архитектуру данных с тегами для запланировать выполнение узлов в графе через один или несколько исполнительных блоков. Вычисления потока данных довольно хорошо подходят для ситуаций, в которых запуск вычислений асинхронно, порождающий каскады вычислений, работает лучше, чем попытки управлять выполнением по часам (или часам).

Реактивное программирование импортирует эту идею «каскада выполнения» и, кажется, думает о программе в стиле потока данных, но с условием, что некоторые из узлов подключены к «внешнему миру», и каскады выполнения запускаются, когда эти сенсорные -подобные узлы меняются. Тогда выполнение программы будет похоже на сложную рефлекторную дугу. Программа может быть или не быть в основном сидячей между стимулами или может переходить в практически сидячее состояние между стимулами.

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

Прочитав множество страниц о FRP, я наконец наткнулся на это Поучительные статьи о FRP, наконец, заставили меня понять, что такое FRP на самом деле.

Ниже цитирую Генриха Апфельмуса (автора реактивного банана).

В чем суть функционального реактивного программирования?

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

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

Например, возьмем пример счетчика: у вас есть две кнопки с надписью «Вверх» и «Вниз», которые можно использовать для увеличения или уменьшения счетчика. В обязательном порядке вы должны сначала указать начальное значение, а затем изменять его при каждом нажатии кнопки; что-то вроде этого:

counter := 0                               -- initial value
on buttonUp   = (counter := counter + 1)   -- change it later
on buttonDown = (counter := counter - 1)

Дело в том, что во время объявления указывается только начальное значение счетчика; динамическое поведение счетчика неявно присутствует в остальной части текста программы. Напротив, функциональное реактивное программирование определяет все динамическое поведение во время объявления, например:

counter :: Behavior Int
counter = accumulate ($) 0
            (fmap (+1) eventUp
             `union` fmap (subtract 1) eventDown)

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

Итак, в моем понимании программа FRP - это набор уравнений:

j дискретно: 1,2,3,4 ...

f зависит от t, поэтому это включает возможность моделирования внешних стимулов.

все состояние программы заключено в переменные x_i

Библиотека FRP заботится о времени выполнения, другими словами, переводя j в j+1.

Я объясняю эти уравнения более подробно в этом видео.

РЕДАКТИРОВАТЬ:

Примерно через 2 года после первоначального ответа я недавно пришел к выводу, что реализации FRP имеют еще один важный аспект. Они должны (и обычно решают) важную практическую проблему: недействительность кеша.

Уравнения для x_i-s описывают граф зависимостей. Когда некоторые из x_i изменяются во время j, тогда не нужно обновлять все другие x_i' значения в j+1, поэтому не все зависимости нужно пересчитывать, потому что некоторые x_i' могут быть независимыми от x_i.

Кроме того, x_i-ы, которые действительно изменяются, можно постепенно обновлять. Например, давайте рассмотрим операцию карты f=g.map(_+1) в Scala, где f и g равны List из Ints. Здесь f соответствует x_i(t_j), а g - x_j(t_j). Теперь, если я добавлю элемент к g, было бы расточительно выполнять операцию map для всех элементов в g. Некоторые реализации FRP (например, ) стремятся решить эту проблему. Эта проблема также известна как инкрементные вычисления.

Другими словами, поведение (x_i-s) в FRP можно рассматривать как кэшированные вычисления. Задачей механизма FRP является эффективное аннулирование и повторное вычисление этих кеш-памяти (x_i-s), если некоторые из f_i-s действительно изменяются.

Статья Просто эффективная функциональная реактивность Конала Эллиотта (прямой PDF, 233 КБ) - довольно хорошее введение. Соответствующая библиотека тоже работает.

Этот документ теперь заменен другим документом, Функциональное реактивное программирование типа "пуш-пул" (прямой PDF, 286 КБ) .

Отказ от ответственности: мой ответ относится к rx.js - библиотеке «реактивного программирования» для Javascript.

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

Основные преимущества использования наблюдаемого:
i) он абстрагирует состояние от вашего кода, например, если вы хотите, чтобы обработчик событий запускался только для каждого n-го события или прекращал срабатывание после первого n 'событий, или запускать запуск только после первых' n 'событий, вы можете просто использовать HoFs (filter, takeUntil, skip соответственно) вместо установки, обновления и проверки счетчиков.
ii) это улучшает локальность кода - если вы иметь 5 разных обработчиков событий, изменяющих состояние компонента, вы можете объединить их наблюдаемые и вместо этого определить один обработчик событий на объединенном наблюдаемом, эффективно объединяя 5 обработчиков событий в 1. Это позволяет очень легко понять, какие события во всем вашем system может влиять на компонент, поскольку все это присутствует в одном обработчике.

• Observable - это двойник Iterable.

Iterable - это лениво потребляемая последовательность: каждый элемент извлекается итератором всякий раз, когда он хочет его использовать, и, следовательно, перечисление управляется потребителем.

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

Чувак, это чертовски блестящая идея! Почему я не узнал об этом еще в 1998 году? В любом случае, вот моя интерпретация учебника Fran. Предложения приветствуются, я думаю о запуске игрового движка на его основе.

import pygame
from pygame.surface import Surface
from pygame.sprite import Sprite, Group
from pygame.locals import *
from time import time as epoch_delta
from math import sin, pi
from copy import copy

pygame.init()
screen = pygame.display.set_mode((600,400))
pygame.display.set_caption('Functional Reactive System Demo')

class Time:
    def __float__(self):
        return epoch_delta()
time = Time()

class Function:
    def __init__(self, var, func, phase = 0., scale = 1., offset = 0.):
        self.var = var
        self.func = func
        self.phase = phase
        self.scale = scale
        self.offset = offset
    def copy(self):
        return copy(self)
    def __float__(self):
        return self.func(float(self.var) + float(self.phase)) * float(self.scale) + float(self.offset)
    def __int__(self):
        return int(float(self))
    def __add__(self, n):
        result = self.copy()
        result.offset += n
        return result
    def __mul__(self, n):
        result = self.copy()
        result.scale += n
        return result
    def __inv__(self):
        result = self.copy()
        result.scale *= -1.
        return result
    def __abs__(self):
        return Function(self, abs)

def FuncTime(func, phase = 0., scale = 1., offset = 0.):
    global time
    return Function(time, func, phase, scale, offset)

def SinTime(phase = 0., scale = 1., offset = 0.):
    return FuncTime(sin, phase, scale, offset)
sin_time = SinTime()

def CosTime(phase = 0., scale = 1., offset = 0.):
    phase += pi / 2.
    return SinTime(phase, scale, offset)
cos_time = CosTime()

class Circle:
    def __init__(self, x, y, radius):
        self.x = x
        self.y = y
        self.radius = radius
    @property
    def size(self):
        return [self.radius * 2] * 2
circle = Circle(
        x = cos_time * 200 + 250,
        y = abs(sin_time) * 200 + 50,
        radius = 50)

class CircleView(Sprite):
    def __init__(self, model, color = (255, 0, 0)):
        Sprite.__init__(self)
        self.color = color
        self.model = model
        self.image = Surface([model.radius * 2] * 2).convert_alpha()
        self.rect = self.image.get_rect()
        pygame.draw.ellipse(self.image, self.color, self.rect)
    def update(self):
        self.rect[:] = int(self.model.x), int(self.model.y), self.model.radius * 2, self.model.radius * 2
circle_view = CircleView(circle)

sprites = Group(circle_view)
running = True
while running:
    for event in pygame.event.get():
        if event.type == QUIT:
            running = False
        if event.type == KEYDOWN and event.key == K_ESCAPE:
            running = False
    screen.fill((0, 0, 0))
    sprites.update()
    sprites.draw(screen)
    pygame.display.flip()
pygame.quit()

Вкратце: если каждый компонент можно рассматривать как число, всю систему можно рассматривать как математическое уравнение, не так ли?

Книга Пола Худака The Haskell School of Expression - это не только штраф введение в Haskell, но он также уделяет много времени FRP. Если вы новичок в FRP, я настоятельно рекомендую его, чтобы вы получили представление о том, как работает FRP.

Есть также то, что выглядит как новая версия этой книги (выпущена в 2011 г., обновлена ​​в 2014 г.), Музыкальная школа Haskell.

Согласно предыдущим ответам, кажется, что математически мы просто мыслим в более высоком порядке. Вместо того чтобы думать, что значение x имеет тип X, мы думаем о функции x: T → X, где T - тип времени, будь то натуральные числа, целые числа или континуум. Теперь, когда мы пишем y: = x + 1 на языке программирования, мы фактически имеем в виду уравнение y (t ) = x (t) + 1.