Question

I’m implementing an FRP framework in Scala and I seem to have run into a problem. Motivated by some thinking, this question I decided to restrict the public interface of my framework so Behaviours could only be evaluated in the ‘present’ i.e.:

behaviour.at(now) 

This also falls in line with Conal’s assumption in the Fran paper that Behaviours are only ever evaluated/sampled at increasing times. It does restrict transformations on Behaviours but otherwise we find ourselves in huge problems with Behaviours that represent some input:

val slider = Stepper(0, sliderChangeEvent) 

With this Behaviour, evaluating future values would be incorrect and evaluating past values would require an unbounded amount of memory (all occurrences used in the ‘slider’ event would have to be stored).

I am having trouble with the specification for the ‘snapshot’ operation on Behaviours given this restriction. My problem is best explained with an example (using the slider mentioned above):

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

My problem here is that if the ‘mouseB’ Event has occurred when this code is executed then the current value of ‘stepper’ will be the last ‘sample’ of ‘slider’ (the value at the time the last occurrence occurred). If the time of the last occurrence is in the past then we will consequently end up evaluating ‘slider’ using a past time which breaks the rule set above (and your original assumption). I can see a couple of ways to solve this:

1. We ‘record’ the past (keep hold of all past occurrences in an Event) allowing evaluation of Behaviours with past times (using an unbounded amount of memory)
2. We modify ‘snapshot’ to take a time argument (“sample after this time”) and enforce that that time >= now
3. In a more wacky move, we could restrict creation of FRP objects to the initial setup of a program somehow and only start processing events/input after this setup is complete

I could also simply not implement ‘sample’ or remove ‘stepper’/’switcher’ (but I don’t really want to do either of these things). Has anyone any thoughts on this? Have I misunderstood anything here?

Answer 1

Oh I see what you mean now.

Your “you can only sample at ‘now'” restriction isn’t tight enough, I think. It needs to be a bit stronger to avoid looking into the past. Since you are using an environmental conception of now, I would define the behavior construction functions in terms of it (so long as now cannot advance by the mere execution of definitions, which, per my last answer, would get messy). For example:

Stepper(i,e) is a behavior with the value i in the interval [now,e1] (where e1 is the
time of first occurrence of e after now), and the value of the most recent occurrence of e afterward.

With this semantics, your prediction about the value of stepper that got you into this conundrum is dismantled, and the stepper will now have the value 0. I don’t know whether this semantics is desirable to you, but it seems natural enough to me.