
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.
For example the "plugging a space leak with an arrow" papers reduces the
recursive signal problem to
e = integral 1 e
Maybe the Nlift problem is a good example for dynamic collections, but I
guess we'll need more examples.
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?
On Wed, Apr 15, 2009 at 6:39 PM, Claus Reinke
but the fact that the breakout example works is an indication that at
least it's not hopelessly broken.
Well, a breakout game does *not* work (yet) in most other FRP implementations except Yampa, which do have firm theoretical foundations :-)
While certainly more entertaining, the problem looks similar enough 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 to test some expressiveness aspects of the language:
- a dynamically updated collection (requests in NLift, bricks in breakout) - an object moving in response to user input (lift/paddle+ball) - collection and object reacting to each other's relative positions (lift at floor levels/paddle ball brick collisions)
In NLift, user input (keyboard) adds to the requests collection, and the 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.
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 "other FRP libraries", with variations of approach/concepts.
Claus
[0] http://community.haskell.org/~claus/FunWorlds/NLift.hs [1] http://community.haskell.org/~claus/FunWorlds/ [2] http://community.haskell.org/~claus/FunWorlds/VRML/
FunWorlds/OpenGL in brief:
- a behaviour is a description of an experiment
- a behaviour can be sampled (performing the experiment), yielding a current value and a residual behaviour (the latter replaces the original behaviour)
- the results of measurements can be broadcast and observed via behavioural channels (a channel observer simply behaves as the channel source behaviour, with a slight delay)
That's it! The is no special role for time at all. One can establish local clocks, one can even broadcast their ticking behaviours. But one cannot take an arbitrary absolute time and ask for the value of a behaviour at that time (other than actually running that behaviour forward or backward from "now").
Also, there is a natural distinction between describing and running a behaviour, with the ability to refer to either the description or to sample outcomes. And having the same behaviour description on both sides of an event in a stepper/until does not mean that nothing changes at the step: the second copy doesn't continue where the first left off, but starts from its own beginning (with no special tricks to achieve this). There are no separate events, and delays enter via behavioural channels.
Well, there were lots of negatives as well (eg FunWorlds was an "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 work out the details and clean up/modernize the interface, but without funding, it'll just have to wait until I get round to it (or one of the newer FRP libraries renders it superfluous..).
If you try the examples, you'll notice that some of them run too fast on modern machines (because they weren't tied to an external clock), so 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').