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

[Peter Verswyvelen]

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 <claus.reinke at talk21.com>wrote:

> 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').
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090416/9d7bbc47/attachment.htm