I think it would be nice if we could make a "reactive benchmark" or something: some tiny examples that capture the essence of reactive systems, and a way to compare each solution's pros and cons.<div><br></div>
<div><div>For example the "plugging a space leak with an arrow" papers reduces the recursive signal problem to<br></div><div><br></div><div>e = integral 1 e</div><div><br></div><div>Maybe the Nlift problem is a good example for dynamic collections, but I guess we'll need more examples.</div>
<div><br></div><div>The reason why I'm talking about examples and not semantics is because the latter seems to be pretty hard to get right for FRP?</div><div><br></div><div><div><div class="gmail_quote">On Wed, Apr 15, 2009 at 6:39 PM, Claus Reinke <span dir="ltr"><<a href="mailto:claus.reinke@talk21.com">claus.reinke@talk21.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
but the fact that the breakout example works is an indication that at<br>
least it's not hopelessly broken.<br>
</blockquote></div>
Well, a breakout game does *not* work (yet) in most other FRP<div class="im"><br>
implementations except Yampa, which do have firm theoretical foundations :-)<br>
</div></blockquote>
<br>
While certainly more entertaining, the problem looks similar enough<br>
to the NLift example (a lift serving requests on n floors[0]) in FunWorlds (the 2002 OpenGL version[1], not the 2001 VRML version[2]), chosen<br>
to test some expressiveness aspects of the language:<br>
<br>
- a dynamically updated collection (requests in NLift, bricks in breakout)<br>
- an object moving in response to user input (lift/paddle+ball)<br>
- collection and object reacting to each other's relative positions (lift at floor levels/paddle ball brick collisions)<br>
<br>
In NLift, user input (keyboard) adds to the requests collection, and the<br>
lift reacts to the request collection and its own status, while in breakout, user input (mouse) directly controls the paddle, to which the ball reacts. The lift stopping at a floor directly removes a request there, while breakout bricks disappear when hit by the additional ball. In NLift, collisions and movement are one-dimensional, while breakout is two-dimensional.<br>
<br>
On the other hand, I hadn't got round to cleaning up the interface, let alone firming the theoretical foundations, so perhaps this isn't an exception to your rule?-) But I thought I'd mention it on the topic of<br>
"other FRP libraries", with variations of approach/concepts.<br>
<br>
Claus<br>
<br>
[0] <a href="http://community.haskell.org/~claus/FunWorlds/NLift.hs" target="_blank">http://community.haskell.org/~claus/FunWorlds/NLift.hs</a><br>
[1] <a href="http://community.haskell.org/~claus/FunWorlds/" target="_blank">http://community.haskell.org/~claus/FunWorlds/</a><br>
[2] <a href="http://community.haskell.org/~claus/FunWorlds/VRML/" target="_blank">http://community.haskell.org/~claus/FunWorlds/VRML/</a><br>
<br>
FunWorlds/OpenGL in brief:<br>
<br>
- a behaviour is a description of an experiment<br>
<br>
- a behaviour can be sampled (performing the experiment), yielding a current<br>
value and a residual behaviour (the latter replaces the original behaviour)<br>
<br>
- the results of measurements can be broadcast and observed via behavioural<br>
channels (a channel observer simply behaves as the channel source behaviour,<br>
with a slight delay)<br>
<br>
That's it! The is no special role for time at all. One can establish local<br>
clocks, one can even broadcast their ticking behaviours. But one cannot take an<br>
arbitrary absolute time and ask for the value of a behaviour at that time<br>
(other than actually running that behaviour forward or backward from "now").<br>
<br>
Also, there is a natural distinction between describing and running a<br>
behaviour, with the ability to refer to either the description or to sample<br>
outcomes. And having the same behaviour description on both sides of an event<br>
in a stepper/until does not mean that nothing changes at the step: the second<br>
copy doesn't continue where the first left off, but starts from its own<br>
beginning (with no special tricks to achieve this). There are no separate<br>
events, and delays enter via behavioural channels.<br>
<br>
Well, there were lots of negatives as well (eg FunWorlds was an<br>
"engine-exposed" workbench rather than a user-directed library), but I thought I'd try to get you interested first!-) I'd love to have funding to<br>
work out the details and clean up/modernize the interface, but without<br>
funding, it'll just have to wait until I get round to it (or one of the newer<br>
FRP libraries renders it superfluous..).<br>
<br>
If you try the examples, you'll notice that some of them run too fast on<br>
modern machines (because they weren't tied to an external clock), so<br>
you'd have to slow them down (eg, Surface and Torus, in addition to the standard rotate/scale controls, also react to 't'/'T' for scaling time) but they are are still fun to watch in their naivete (try Boids for simplicity, Flock2 for chaos - you'll need to scale it 's'/'S').<br>
<br>
<br>
</blockquote></div><br></div></div></div>