Функциональное реактивное программирование на Erlang

[Никита Нежевский]

Всем привет.

В одном из проектов возникла необходимость использовать FRP. Поиск в гугле и на гитхабе не дал никаких результатов (всё, что было найдено - бестолковая учебная библиотека).

Существует ли какое-нибудь готовое решение? Если нет, можно ли как-нибудь смоделировать функциональную реактивную парадигму? (на данный момент логика реализована с помощью gen_event и это не слишком удобно) 

[the.silly.sad]

you already have "asynchronous message passing" in erlang.
what else do you need.

[Vladimir Gordeev]

> смоделировать функциональную реактивную парадигму

Опишите чего конкретно вы хотите. По-моему в Erlang всё есть.

--
Вы получили это сообщение, поскольку подписаны на группу Erlang по-русски.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russian+unsubscribe@googlegroups.com.
Чтобы добавлять сообщения в эту группу, отправьте письмо по адресу erlang-russian@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[Danil A. Zagoskin]

Часть беды в том, что под FRP понимают немного разные вещи.

Стандартное понимание — когда наружу торчат какие-то входы и выходы, в системе определены чистые функции от входов и промежуточных результатов, на выходе имеются результаты, которые реагируют на изменение входных данных ASAP. Хороший пример реализации FRP — Excel с его формулами.

Некоторые углубляются в буквоедство, и заявляют, что Эрланг — функционален, реактивен (принял событие — обработал — сделал что-то) и язык программирования, поэтому он якобы сам по себе является FRP-системой.

Далее я буду говорить о стандартном, на мой взгляд (первом) понимании.

Я готовых реализаций не помню и сомневаюсь не только в возможности их нормальной реализации на эрланге, но и в целесообразности этой затеи.

Возьмем простой пример FRP-системы.

Пусть у нас есть на входе три числа a, b, c. Пусть система определяет функции f(a,b), g(b,c), h(a,b,c), j(f,h), k(g,j), l(f, k).

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

Асинхронные системы типа эрланга очень плохо подходят для таких задач, потому что при графе с достаточно большим количеством ребер от малейшего изменения значения на входе возникает лавина пересчета — в нашем примере, изменив b, мы при наивном устройстве системы «один актор на функцию» спровоцируем пересчет одной лишь функции l 4 раза (если я не ошибся). из них только последний вариант будет верным, а промежуточные — непонятно чем. А что произойдет, если где-то в середине процесса пересчета от одного изменения входа изменится еще один вход?

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

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

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

P.S.: есть несколько схожая концепция «Dataflow programming», которая к эрлангу как раз очень применима, и, если я правильно понимаю, прекрасно реализуется при помощи Riak Pipe.

--

Вы получили это сообщение, поскольку подписаны на группу "Erlang по-русски".

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес erlang-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[the.silly.sad]

On 02/19/2015 12:22 PM, Danil A. Zagoskin wrote:
> спровоцируем пересчет одной лишь функции l 4 раза (если я не ошибся). из
> них только последний вариант будет верным

в обсчем случаэ ето неверноэ утверждение.
функцея 'l' не обязана быть pure.
а ФРП допускаэт или даже предлагает иметй на месте етой функции конечный
автомат со стеком.

вообще, если искатй в слове "ФРП" какой-либо вразумителйный смысл, то
"ФРП" ето новое имя для стей конечных автоматов.

ФРП ето либо конечноавтоматная сеть.
либо безсмысленный маркетинговый лозунг.

выбирай.

[the.silly.sad]

> Пусть у нас есть на входе три числа a, b, c. Пусть система определяет
> функции f(a,b), g(b,c), h(a,b,c), j(f,h), k(g,j), l(f, k).

could you please provide any sensible usecase (assuming PURITY of all
functions given) except for a "spreadsheet" ?

it is not a sarcasm.

> Нечто изменяет входы a и b (в простом случае — одной транзакцией, в более
> сложном — второй через миллисекунду после первого).

there is no such thing as "миллисекунд" in real life of a program.

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

Erlang does it much better:
"NO SHARED STATE".

> еще, наверное, целая куча проблем,

которые ты сам токашо создал

> При реализации FRP-системы на эрланге придется реализовать какие-то
> алгоритмы обхода графов (можно ли это сделать хоть сколь-нибудь
> эффективно?),

yes, all sorts of recursion with optimization.

>> В одном из проектов возникла необходимость использовать FRP.

и вот кстате топикстартеру вопрос, как ета необходимостй выглядид,
учитывая Turing Completeness всего что у нас есть, как ты определяеш
"НЕОПХОДИМОСТь", когда у нас базовоэ свойство всего: "всё обходимо".

[Danil A. Zagoskin]

2015-02-19 14:58 GMT+03:00 the.silly.sad <the.si...@gmail.com>:

Пусть у нас есть на входе три числа a, b, c. Пусть система определяет
функции f(a,b), g(b,c), h(a,b,c), j(f,h), k(g,j), l(f, k).

could you please provide any sensible usecase (assuming PURITY of all functions given) except for a "spreadsheet" ?

it is not a sarcasm.

Trading bot, UAV control.

 

Нечто изменяет входы a и b (в простом случае — одной транзакцией, в более
сложном — второй через миллисекунду после первого).

there is no such thing as "миллисекунд" in real life of a program.

There are millisecond-precision events on markets and during flight.

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

Erlang does it much better:
"NO SHARED STATE".

еще, наверное, целая куча проблем,

которые ты сам токашо создал

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

yes, all sorts of recursion with optimization.

And also complicated memoization. 

В одном из проектов возникла необходимость использовать FRP.

и вот кстате топикстартеру вопрос, как ета необходимостй выглядид,
учитывая Turing Completeness всего что у нас есть, как ты определяеш "НЕОПХОДИМОСТь", когда у нас базовоэ свойство всего: "всё обходимо".

--
Вы получили это сообщение, поскольку подписаны на группу Erlang по-русски.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russian+unsubscribe@googlegroups.com.

[Никита Нежевский]

Работа программы определяется событиями.

1. (по таймеру) запрашиваются данные

2. Когда (или если) данные приходят, они должны попасть к подписавшемуся именно на них (на определенную группу данных) процессу. Или не попасть никуда, если на них никто не подписывался.

На данный момент это реализовано через gen_server, но это создаёт неудобства. Хотелось бы более подходящего решения.

четверг, 19 февраля 2015 г., 13:51:10 UTC+3 пользователь Vladimir Gordeev написал:

> смоделировать функциональную реактивную парадигму

Опишите чего конкретно вы хотите. По-моему в Erlang всё есть.

2015-02-19 12:15 GMT+02:00 the.silly.sad <the.si...@gmail.com>:

you already have "asynchronous message passing" in erlang.
what else do you need.

On 02/18/2015 07:30 PM, Никита Нежевский wrote:

Всем привет.

В одном из проектов возникла необходимость использовать FRP. Поиск в гугле
и на гитхабе не дал никаких результатов (всё, что было найдено -
бестолковая учебная библиотека).

Существует ли какое-нибудь готовое решение? Если нет, можно ли как-нибудь
смоделировать функциональную реактивную парадигму? (на данный момент логика
реализована с помощью gen_event и это не слишком удобно)

--
Вы получили это сообщение, поскольку подписаны на группу Erlang по-русски.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
Чтобы добавлять сообщения в эту группу, отправьте письмо по адресу erlang-...@googlegroups.com.

[the.silly.sad]

> 1. (по таймеру) запрашиваются данные

chem eto otlichno ot gen_server??

[Никита Нежевский]

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

четверг, 19 февраля 2015 г., 16:59:07 UTC+3 пользователь Silly Sad написал:

[the.silly.sad]

>>> 1. (по таймеру) запрашиваются данные

>> chem eto otlichno ot gen_server??

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

тоестй твоя задача -- Написать клиента, для какогото предопределённого
сервера.
ок, нахрена ты взял gen_server.

бери либу для нужного тебе протокола и пиши клиента

[Grey Kristy]

On Thursday, February 19, 2015 at 5:05:31 PM UTC+3, Никита Нежевский wrote:

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

В эрланге, по сути, кроме ген.серверов и супервайзеров ничего и нет. Так что если gen_server не подходит, надо смотреть что-то другое

 

[Никита Нежевский]

четверг, 19 февраля 2015 г., 18:46:34 UTC+4 пользователь Grey Kristy написал:

> On Thursday, February 19, 2015 at 5:05:31 PM UTC+3, Никита Нежевский wrote:
> Данные запрашиваются из внешнего источника, во много потоков, и они могут получаться достаточно долго. gen_server мне показался неподходящим решением
>
>
>
>
> В эрланге, по сути, кроме ген.серверов и супервайзеров ничего и нет. Так что если gen_server не подходит, надо смотреть что-то другое
>
>
>  

Дело не в gen_server.
Есть 2 типа процессов, у каждого из них есть свой тип событий.
1 тип по таймеру должен получать новые данные.
И тип 2. При получении типом 1 новых данных, должно появляться новое событие. Процесс из типа 2 должен перехватывать события получения тех данных, которые предназначаются именно ему.

Сейчас все это реализовано с помощью обработчиков gen_event, но это не слишком удобно, и мне нужно более подходящее решение

[the.silly.sad]

operator '!'

[Danil A. Zagoskin]

А чем неудобен gen_event в такой схеме?

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

Схематичная схема потоков событий:

Rcv1 -> GE1

Rcv2 -> GE2

Rcv3 -> GE3

[GE1, GE2, GE3] -> Logic

Ну, для удобства можно обернуть связку Rcv-GE в какой-нибудь свой интерфейс, который запустит обоих по запросу от логики. Хотя, если экземпляр логики только один, можно просто супервизорами всю связку разрулить.

--
Вы получили это сообщение, поскольку подписаны на группу Erlang по-русски.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.

[Grey Kristy]

On Thursday, February 19, 2015 at 7:00:22 PM UTC+3, Silly Sad wrote:

operator '!'

+1 

ну или gproс:send если потребителей очень много разных