[Haskell-cafe] ANN: Elerea, another FRP library

[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').