Реализация снимка в FRP

Question

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

behaviour.at(now) 

. Это также соответствует предположению Конала во франции.бумага, в которой Поведения оцениваются / отбираются только в возрастающее время.Он ограничивает преобразования в поведении, но в противном случае мы находимся в огромных проблемах с поведением, которое представляет некоторый ввод:

val slider = Stepper(0, sliderChangeEvent) 

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

У меня возникли проблемы со спецификацией для операции «моментальный снимок» в поведении с учетом этого ограничения.Моя проблема лучше всего объясняется на примере (с использованием ползунка, упомянутого выше):

val event = mouseB // an event that occurs when the mouse is pressed 
val sampler = slider.snapshot(event) 
val stepper = Stepper(0, sampler) 

Моя проблема здесь в том, что если при выполнении этого кода произошло событие «mouseB», то текущее значение «stepper»'будет последним' образцом 'ползунка (значение во время последнего вхождения).Если время последнего вхождения прошло, то мы в итоге будем оценивать «ползунок», используя прошедшее время, которое нарушает установленное выше правило (и ваше исходное предположение).Я вижу несколько способов решить эту проблему:

1. Мы «записываем» прошлое (сохраняем все прошлые события в событии), позволяя оценивать поведение с прошедшими временами (используя неограниченное количествопамять)
2. Мы модифицируем «снимок», чтобы принимать аргумент времени («образец после этого времени») и принудительно установить, что это время> = сейчас
3. В более дурацком движении мы могли бы ограничить созданиеFRP объектов для начальной настройки программы каким-либо образом и только начать обработку событий / ввода после того, как эта установка завершена

Я также мог бы просто не реализовать 'sample' или удалить 'stepper' / 'switcher'(но я действительно не хочу делать ни одну из этих вещей).У кого-нибудь есть мысли по этому поводу?Я что-то здесь неправильно понял?

Answer 1

О, я понимаю, что ты имеешь в виду сейчас.

Я думаю, что твое ограничение "ты можешь выбирать только" сейчас "недостаточно жесткое.Это должно быть немного сильнее, чтобы не заглядывать в прошлое.Поскольку вы используете экологическую концепцию now, я бы определил функции построения поведения в терминах ее (до тех пор, пока now не сможет продвинуться простым исполнением определений, что, согласно моему последнему ответу, будет грязным),Например:

Stepper(i,e) - это поведение со значением i в интервале [now,e1] (где e1 - время первого появления e после now)и значение самого последнего вхождения e впоследствии.

С этой семантикой ваше предсказание о значении stepper, которое привело вас в эту головоломку, будет отменено, и степпер будеттеперь имеют значение 0. Я не знаю, желательна ли вам эта семантика, но она кажется мне достаточно естественной.

Answer 2

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

Чисто функциональный код не хочет иметьзнаю, что это выполняется.Функциональные приемы являются лучшими в чистом виде, так что не имеет значения, в каком коде заказа выполняется.Выход из этой дилеммы - сделать вид, что каждое изменение произошло в одном чувствительном (внутреннем, вероятно) фрагменте императивного кода;притвориться, что любые функциональные объявления в структуре FRP происходят за 0 раз, поэтому невозможно что-то изменить во время их объявления.

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

Это не обязательно исключает запуск его в нескольких потоках, но для поддержки этого вам может потребоваться реорганизация внутреннегопредставления.Добро пожаловать в мир внедрения библиотеки FRP - я подозреваю, что ваше внутреннее представление будет колебаться много раз в течение этого процесса.: -)

Answer 3

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

В момент, когда происходит событие mouseB, будет прочитано значение поведения slider (snapshot).Это значение будет «установлено» в поведение stepper.

Таким образом, верно, что Stepper будет «запоминать» значения из прошлого;Дело в том, что он запоминает только последнее значение из прошлого, а не все.

Семантически лучше всего моделировать Stepper как функцию, предложенную Луки.