По циклам - а как же vbs?

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

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

Есть 2 главных стратегии при изменении одной из ячеек;

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

2. Просто класть замыкания в зависимые ячейки. Тогда если снаружи придёт запрос "дай мне значение ячейки X421", шестерёнки начинают крутиться и весь граф всех данных, которые влияют на данное значение начинает вычисляться. Это очень близко к ленивым вычислениям в Хаскеле. (это pull модель)

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

А чё ты изначально то хотел сказать?

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

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

Есть 2 главных стратегии при изменении одной из ячеек;

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

2. Просто класть замыкания в зависимые ячейки. Тогда если снаружи придёт запрос "дай мне значение ячейки X421", шестерёнки начинают крутиться и весь граф всех данных, которые влияют на данное значение начинает вычисляться. Это очень близко к ленивым вычислениям в Хаскеле. (это pull модель)

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

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

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

Есть 2 главных стратегии при изменении одной из ячеек;

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

2. Просто класть замыкания в зависимые ячейки. Тогда если снаружи придёт запрос "дай мне значение ячейки X421", шестерёнки начинают крутиться и весь граф всех данных, которые влияют на данное значение начинает вычисляться. Это очень близко к ленивым вычислениям в Хаскеле. (это pull модель)

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

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

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

Есть 2 главных стратегии при изменении одной из ячеек;

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

2. Просто класть замыкания в зависимые ячейки. Тогда если снаружи придёт запрос "дай мне значение ячейки X421", шестерёнки начинают крутиться и весь граф всех данных, которые влияют на данное значение начинает вычисляться. Это очень близко к ленивым вычислениям в Хаскеле. (это pull модель)

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

Так при 2 подходе мы тоже можем не пересчитывать, если не надо. Дедупы же, дедупы повсюду)

Ну тут остается заметить, что reactive - типичная монадка)

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

Ну тут остается заметить, что reactive - типичная монадка)

Забавно, а в чем проблема с выражением монады

Забавно, а в чем проблема с выражением монады

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

Вот тебе тл;др:

https://twitter.com/withoutboats/status/1027702531361857536

https://varkor.github.io/blog/2019/03/28/idiomatic-monads-in-rust.html

@DogeShibu ты с этим согласен?