The Synchronous Blog

Good news received last week:

Dear Mr. Francisco Sant’Anna,

I am pleased to confirm that your paper “LuaGravity, a Reactive Language
Based on Implicit Invocation” has been accepted for presentation and
publication at SBLP 2009.

All papers went through a rigorous reviewing process by the program
committee. Out of 30 research papers and 3 tutorials submitted, 12
papers and 1 tutorial were accepted.

Please make sure that in the preparation of the final paper you
carefully address the reviewers’ comments. Additionally, at least one
author is required to register in the conference for your paper to
appear in the proceedings.

Congratulations again on having your paper accepted. We look forward to
seeing you in Gramado!

Reviewer’s comments already addressed and final version submitted! One reviewer in particular pointed several constructive observations, which we took very seriously in the final version.

Follows the abstract for the paper:

The reactive programming paradigm covers a wide range of applications, such as
games and multimedia systems.
Mainstream languages do not offer proper support for reactive programming,
lacking language-level primitives that focus on synchronism and interactions
within application parts.
We propose an imperative reactive language, called LuaGravity, based on
unconventional implicit invocation mechanisms.
LuaGravity allows dataflow programming, sequential imperative execution, and
deterministic use of shared-memory.
With this work, we intend to unite the essential features of reactive languages
while keeping a convenient imperative style of programming.

SBLP [1] is the main Brazilian congress on programming languages. This year it will be held in Gramado on August 18-21.

[1] http://sblp2009.ucpel.tche.br/

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 definition, posting and handling: they are all done implicitly.
However, in another post, we pointed out three issues in this paradigm: inversion of control, multi-core processors and listener life cycle.

This post deals with the first and more annoying limitation of event-driven programming: inversion of control.
Event-driven programming demands that its callbacks execute very fast as the event handling is serialized: while one event is being handled, others are not – only one callback executes at a time.
Callbacks are, therefore, logically instantaneous and can’t hold state. They commonly receive state (those void* parameters), decode it (to work like a state machine and know where it was left), update it and return.
The sequential execution paradigm is broken here, as control is now guided by the event queue (the environment).

LuaGravity supports reactivity inside its methods in some way like Esterel does.
The AWAIT primitive suspends the execution of a method and waits for another method (or timer) to happen.
For example, AWAIT(keyboard.ENTER.press) suspends the running method until ENTER is pressed.
AWAIT is like a LINK, but is broken when its condition happens and resumes (instead of calling) the suspended method.

A little bit confusing, huh?
Hope the following example helps.
Let’s say we want an animation to change its direction following the sequence RIGHT, DOWN, LEFT and UP when the respective keys are pressed.
Without using the AWAIT primitive, we need to hold state between successive executions of animation.changeDirection:

-- WITHOUT AWAIT
LINK(RIGHT.press,  animation.changeDirection)
LINK(DOWN.press, animation.changeDirection)
LINK(LEFT.press,    animation.changeDirection)
LINK(UP.press,       animation.changeDirection)

function animation.changeDirection (key)
    if (obj.state == 'right') and (key == 'DOWN') then
        obj.state = 'down'
        obj.x = obj.x()                -- stay here
        obj.y = obj.y() + S(obj.speed) -- move down

    elseif (obj.state == 'down') and (key == 'LEFT') then
        obj.state = 'left'
        obj.x = obj.x() - S(obj.speed) -- move left
        obj.y = obj.y()                -- stay here

    elseif (obj.state == 'left') and (key == 'UP') then
        obj.state = 'up'
        obj.x = obj.x()                -- stay here
        obj.y = obj.y() - S(obj.speed) -- move up

    elseif (obj.state == 'up') and (key == 'RIGHT') then
        obj.state = 'right'
        obj.x = obj.x() + S(obj.speed) -- move right
        obj.y = obj.y()                -- stay here
    end
end

With the use of AWAIT, we code the animation sequentially:

-- WITH AWAIT
while true do
    AWAIT(RIGHT.press)
    obj.x = obj.x() + S(obj.speed)   -- move right
    obj.y = obj.y()                  -- stay here

    AWAIT(DOWN.press)  obj.x = obj.x() -- stay here
    obj.y = obj.y() + S(obj.speed)   -- move down

    AWAIT(LEFT.press)  obj.x = obj.x() - S(obj.speed) -- move left
    obj.y = obj.y()                  -- stay here

    AWAIT(UP.press)
    obj.x = obj.x()                  -- stay here
    obj.y = obj.y() - S(obj.speed)   -- move up
end

In the code above, obj.x() takes its current position, and S(obj.speed) animates the objects (position = integral of speed).
Much cleaner with AWAIT, isn’t?
See the result in the video below:

The full example code can be found here.