Lambda the Ultimate

Of course, I knew I was forgetting something :) Yes, flapjax is what I consider a "function-based" FR system, especially also being modeled after FrTime (the demos are very easy for me to follow!). Now that I'm on break I hope to have time to play around with flapjax and learn how you may have tackled some of the same problems I'm having, especially things like performing asynchronous communications from within an event. (I'm trying to find a way to model modal dialog boxes as functions which could be applied to events without blocking the entire library.) Not to mention bringing my naming scheme up-to-date with yours; I've been trying to keep my API familiar to users of extant FR systems (especially FrTime).

I was trying to narrow down a class of combinators tonight when I stumbled across a first-class event system released in F# earlier this year. It might provide useful contrast implementation-wise given both are in ML and thus have similar implementation constraints.

f# imperative reactive programming

I'm not quite sure what the stumbling block is with asynchronous events so I may be misinterpreting your statement. In FrTime, no new event is popped off the event queue until the dependency graph has stabilized (the previous event has been completely handled so the topological evaluation priority queue is empty). I think parallel or alternating processing of events is possible on the dependency graph if you maintain the invariant that at any step of execution, all older events are being processed higher on the graph than new events - though this may get complicated (and undecidable) due to graph restructuring nodes (like Switch). The desired atomicity of event handling really determines what you can do in terms of concurrent evaluation. I can envision limiting the system without too much harm in practice to a variant of switch whose height is fixed assuming callbacks/messagepassing is permissable (as they should be in an 'imperative' reactive system).

Your example of a modal box, in FrTime and Flapjax, would cause a pop up, and the graph would then stabilize, so the system would then be waiting for more user input and thus also allowing other events in. Perhaps you meant the modal window should prevent some interactions but not all? lift_e(alert, timer_e()); would make an alert of the time every second in the library version, and alert(seconds_e()); in the compiled one. In my experience, io, recursive forms, and collections have been the tricky parts :) We have a couple of neat ideas on collections (barely half-implemented) and I'm mostly concerned with atomicity, optimization, and selectors at this point...

What about in the case of lift_e(confirm, timer_e()), where the program requires the result of the dialog box in order to finish its computation (and, as you point out, to finish restructuring the graph in the case of switch nodes)? I presume[1] incoming events such as timer ticks are postponed until the dialog box is closed (this is what O'Caml RT currently does). In simple GUI applications this is not a problem, but what if the dialog box itself is built from FR components? The components of the dialog box would remain unresponsive until the dialog box is closed! The only solution I can think of to this problem (besides ditching the dialog-box-as-function model) is to allow signal transformers to return an "incomplete" value which can be filled in at a later point (much like futures), but this seems like it would be much more work that it's worth.

Regarding recursive forms, O'Caml RT currently only allows "recursion" in the sense of forward references, not in the sense of actual recursive signals which form a loop and execute until they settle on some value. If the recursive combinators are used to create such a loop the result is undefined. I've (so far) found this restriction not to be limiting.

[1] I'm currently stuck using dial-up on an old Windows machine so I cannot test this in Flapjax; please correct me if I'm wrong!

Flapjax *should* also block if just lifting the confirm call as that is the semantic of confirm and so I'd argue that's the expected behaviour of lift.

An asynchronous_lift, which would take a blocking call and make it non-blocking, would conceivably act like a FrTime delay in that a new hidden node would be created at the bottom of the graph and the result of function application would come at some nondeterministic time later. This usecase is what makes ajax calls natural in flapjax :) In the asynchronous_lift case, given that evaluation in FrTIme is actually single-threaded, a new thread would have to be introduced to perform the evaluation. The engine would now also have support use by multiple threads, but all the means is a synchronized incoming event queue.

In some implementations of javascript, it seems that events are handled in their own threads, so spawning a new thread to handle the event might even work in flapjax. For example, an asynchronous function lift for one reactive argument in Flapjax:


var async_lift_e = function (fn, arg_e) {
var result_e = new Event(); //node with no dependents
lift_e(function (flat_a) { setTimeout( function () { result_e.sendEvent(fn(flat_a)); }, 0 ); }, arg_e);
return result_e;
};

async_lift_e(confirm, timer_e());


where sendEvent injects an event into the event stream and setTimeout(fn, t) will evaluate fn in its own thread t ms after invocation.

Clearly, this would be easier in ocaml as it wouldn't be a series of giant browser-specific hacks; I envy you there :) More generally, allowing control to safely relax the frtime style evaluation order would be useful in terms of performance and specifying modal events. As a solution to a different problem, last summer one of us wanted to try something in an almost STM style, but we never went forward with that line of thought. I think there are clean ways to achieve concurrency/atomicity/blocking in this domain. Hopefully I'll be presenting one as part of my ugrad thesis in a few months :)

Your profile has a link to a wpi website - any chance you worked with Dan D. or Kathi F.?

I think async_lift is exactly the function I need... I initially had been trying to avoid a solution like that because the ordering of events gets lost (since the event coming out of async_lift occurs at a later time than the event going in) but it seems now like the right way to go, so long as these semantics are made explicit. Thanks for the insight! (BTW please post a link to your thesis when you finish, I'd like to see what other results you come up with.)

Your profile has a link to a wpi website - any chance you worked with Dan D. or Kathi F.?

In fact I've worked with both Dan and Kathi; Dan advised me on a project and it was Kathi who introduced me to FrTime in the first place :)

Advice taken!