The Synchronous Blog

A blog about reactive programming languages.

Reactivity in LuaGravity

with 3 comments

The reactivity in LuaGravity is achieved with implicit method invocation. So what?

Suppose we have the following class definition:

MyClass = class {
   function init (self, name)
       self._name = name
   function ping (self)
       print('ping', self._name)
   function pong (self)
       print('pong', self._name)

That is, a simple class with a property name and two methods: ping and pong.

Now we create three objects and link some of their methods:

a = MyClass('a')
b = MyClass('b')
c = MyClass('c')

LINK(, b.pong)
LINK(, a.pong)

Then, a simple call to yields in:

ping    a
pong    b
ping    c
pong    a

That simple! A method is implicitly called in reaction to a call in another condition method.
Comparing to event-driven programming, there’s no need to define or post events, it’s all made implicitly. Much less verbosity.

The reactive variables of LuaGravity (shown here and here) override Lua’s default behavior for attribution.

So that

b = a
a = 2

Is equivalent to

LINK(a.update, b.update)

Variables are, instead, special objects with an update method.

The parameter in a method call is propagated through its link chain as in a pipeline.
This way the value 2 is also passed to b.update.

A simple example of using LuaGravity in multimedia applications would go like this:

LINK(video1.start, video2.start)
LINK(video3.stop,  video4.start)

The first link makes video1 and video2 play in parallel, while the second link makes video3 and video4 play in sequence.

By overloading the operators + and * one could just write:

video1 + video2  -- play in parallel
video3 * video4  -- play in sequence

In LuaGravity, event definition is implicit, event posting is implicit and event linking may also be implicit (through operator overloading).

Given the amount of times the word implicit appears in this text, could LuaGravity be considered an implicit implicit invocation system?


Written by francisco

September 1, 2008 at 12:05 am

3 Responses

Subscribe to comments with RSS.

  1. “The parameter in a method call is propagated through its link chain as in a pipeline.”

    Is the parameter allowed to be changed inside a method call? The link chain would be much more useful if state changes and computation results are propagated through it. This information is not implicit in your text. :)

    P.S.: Quite good syntax, by the way.


    September 5, 2008 at 11:33 am

  2. You are right, it’s not implicit. :)
    The return value of each method in the chain is passed as a parameter to the next method.
    So, it’s possible (and common) that the information in a dataflow is changed from one end to the other as in filters.


    September 5, 2008 at 3:57 pm

  3. […] The LINK reactivity primitive was already presented in this post. LINK makes the use of event-driven paradigm easier, avoiding all the bureaucracy of events […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: