--
Вы получили это сообщение, поскольку подписаны на группу Erlang по-русски.
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russian+unsubscribe@googlegroups.com.
Чтобы добавлять сообщения в эту группу, отправьте письмо по адресу erlang-russian@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/d/optout.
--
Вы получили это сообщение, поскольку подписаны на группу "Erlang по-русски".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес erlang-...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Пусть у нас есть на входе три числа 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 всего что у нас есть, как ты определяеш "НЕОПХОДИМОСТь", когда у нас базовоэ свойство всего: "всё обходимо".
--
Вы получили это сообщение, поскольку подписаны на группу Erlang по-русски.
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russian+unsubscribe@googlegroups.com.
> смоделировать функциональную реактивную парадигму
Опишите чего конкретно вы хотите. По-моему в 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.
Данные запрашиваются из внешнего источника, во много потоков, и они могут получаться достаточно долго. gen_server мне показался неподходящим решением
Дело не в gen_server.
Есть 2 типа процессов, у каждого из них есть свой тип событий.
1 тип по таймеру должен получать новые данные.
И тип 2. При получении типом 1 новых данных, должно появляться новое событие. Процесс из типа 2 должен перехватывать события получения тех данных, которые предназначаются именно ему.
Сейчас все это реализовано с помощью обработчиков gen_event, но это не слишком удобно, и мне нужно более подходящее решение
--
Вы получили это сообщение, поскольку подписаны на группу Erlang по-русски.
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес erlang-russia...@googlegroups.com.
operator '!'