Заботимся ли мы о «прошлом» в FRP?

Играя с внедрением FRP, я обнаружил, что одна вещь сбивает с толку: что делать с прошлым? По сути, я понимал, что смогу сделать это с помощью Behavior в любой момент:

beh.at(x) // where time x < now

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

val beh = Stepper(0, event) // stepwise behaviour

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

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


functional-programming frp haskell semantics programming-languages
person seadowg    schedule 02.03.2012    source источник
comment
Почему это помечено как Haskell, но использует синтаксис Scala? В конце концов, я думаю, что вопрос не зависит от языка :-)   -  person Bergi    schedule 11.09.2014

Ответы (1)


arrow_upward
20
arrow_downward

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

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

Конечно, это приводит к проблеме, заключающейся в том, что возможность видеть только точное настоящее сильно ограничивает ваши возможности при написании функции для преобразования поведения: Behaviour a -> Behaviour b становится таким же, как a -> b, что делает многое мы хотели бы сделать невозможное. Но это скорее вопрос поиска семантики, одной из постоянных проблем FRP, чем что-либо еще; пока примитивные преобразования поведения, которые вы предоставляете, достаточно эффективны, не вызывая утечек времени, все должно быть в порядке. Дополнительную информацию об этом см. в разделе Сбор мусора для семантики FRP.

person ehird    schedule 02.03.2012
comment
Чтобы было ясно: вы имеете в виду, что мы должны иметь возможность вычислить значение поведения только «сейчас»? Я чувствую, что это имеет большой смысл, но я не могу найти, чтобы Конал когда-либо объяснял это... - person seadowg; 07.03.2012
comment
Что ж, вычисление ценности поведения в определенное время — это то, что не предусмотрено самой системой FRP; это способ связать систему FRP с внешним миром. Например, в Haskell такой функцией может быть value :: Behaviour a -> IO a. Но FRP в абстрактном виде существует в мире без IO: поскольку определение поведения — это значение, которое меняется со временем, единственный способ представить текущее значение поведения — это... с помощью поведения! - person ehird; 07.03.2012
comment
Но что касается приклеивания системы FRP к нечистому хост-языку, то либо не предлагается интерфейс для получения значения поведения (вам это может вообще не понадобиться), либо предлагается только интерфейс для получения значения в настоящее время. , кажется, лучший способ обратиться ко мне по причинам, которые я изложил в своем ответе. Ссылка на Conal, которую я дал, была только для семантической проблемы, которую я затронул в последнем абзаце; он не содержит никаких советов по этому вопросу. - person ehird; 07.03.2012
comment
Ах хорошо. Я забыл, что функции в Haskell являются чистыми, и это объясняет, почему эти темы не поднимаются так часто. Я работаю над фреймворком Scala FRP, поэтому я думаю, что на данный момент я просто удалю at и transform (внешне то есть). - person seadowg; 07.03.2012