parallel/or do
        loop do
            await 250ms;
            emit Leds_led0Toggle();
        end;
    with
        loop do
            await 500ms;
            emit Leds_led1Toggle();
        end;
    with
        loop do
            await 1000ms;
            emit Leds_led2Toggle();
        end;
    end;

I realized that syntax really matters after teaching Céu as an alternative to nesC in two courses this year.

The new syntax is more verbose and less flexible, but way more readable.

LuaGravity was very fun to work with, it showed how reactive languages are expressive, allowing complex dependency patterns to be written with simple expressions. It also showed how easily Lua can be hacked in runtime to provide a completely different semantics.

However, LuaGravity is overly powerful as a research artifact. In this context, what really matters is to understand the motivations, goals, and what is needed  and not needed in a reactive language. The border between Lua and LuaGravity was unclear and Lua is too dynamic, what complicates the deterministic execution enforcement we wanted to provide.

The development of a new language—Céu—is the process to answer and pose research questions related to reactive languages.

Céu can be defined in keywords as a reactive, imperative, concurrent, synchronous, and deterministic language. The syntax is very compact (resembling CSP or Pi-calculus), what is great for writing papers and discussing programs, but not necessarily for developing applications.

Currently, Céu is targeted at Wireless Sensor Networks, but any constrained embedded platform is of our interest. Follows a “Hello World!” program in Céu  that blinks three leds, each with a different frequency, forever:

(
    ( ~250ms  ; ~>Leds_led0Toggle)*
||
    ( ~500ms  ; ~>Leds_led1Toggle)*
||
    ( ~1000ms ; ~>Leds_led2Toggle)*
)

.

I presented Céu in the Doctoral Colloquium [1] at Sensys’11 last week. The 3-page summary submitted to the conference can be reached here.

[1] http://www.cse.ust.hk/~lingu/SenSys11DC/

LuaGravity is a reactive language that implements the synchronous approach for concurrency.

It is roughly based on Esterel and FrTime, two reactive synchronous languages, the former having an imperative style, the latter being functional.

LuaGravity is implemented as a set of runtime extensions to the Lua language.

Any feedback is welcome.

Homepage: http://www.lua.inf.puc-rio.br/~francisco/luagravity/

Changes in LuaGravity 0.6:

^ Several changes in the API.
+ `deactivate` and `reactivate` functionality.
+ Support for multiple LuaGravity applications in the same process.
+ Support for the *step execution model*.

Follows the first phrase in Wikipedia’s entry for “Concurrency”:

In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other.

By using the words simultaneously and interacting, this definition captures (for me) the essence of concurrency.

One of the fundamental properties of concurrent systems is their execution model, that is, when should the concurrent computations (I’ll call them concurrent entities) in the system run, and what are the rules that an entity should obey while running.

• Asynchronous Concurrency

In asynchronous execution, entities are in charge of their own control flow and execute independently of each other. Hence, each entity has its own notion of time, not shared globally. The decision to synchronize with other parts of the system is also internal to each entity, and not enforced by the surrounding environment. Depending on the concurrency model in use, these entities are known as threads, actors, processes, tasks, etc.

• Synchronous Concurrency

In synchronous execution, the system flow is controlled by the environment, and internal entities must execute at its pace, in permanent synchrony. Time is now shared between entities and is represented as time steps or as a series of events, both triggered by the surrounding environment.

In my personal experience, when saying “concurrency” people assume asynchronous concurrency, excluding all synchronous reactive languages/systems.

For example, if I state that event-driven programming is a concurrency model, I’ll probably be inquired about this position.

However, if you agree with Wikipedia’s definition and thinks about an event-driven implemented game with hundreds of entities interacting, how can it not be considered “concurrent”?

In a paper from Gerard Berry [1], this “prejudice” is also commented:

Being somewhat unclassical compared to prevalent CSP or CCS based models, it took more time for the synchronous model to be accepted in the mainstream Computer Science community.

Execution model is just one property of concurrent systems. I did not discuss here communication, synchronization, parallelism, determinism…

Maybe it is time to build something like a “Taxonomy for Concurrency”, enumerating all recurrent properties found in concurrency models and languages. Does anyone know about an existing work in this direction?

[1] Gérard Berry, The foundations of Esterel, Proof, language, and interaction: essays in honour of Robin Milner, MIT Press, Cambridge, MA, 2000

LuaGravity is a reactive language that implements the synchronous approach for concurrency.

It is roughly based on Esterel and FrTime, two reactive synchronous languages, the former having an imperative style, the latter being functional.

LuaGravity is implemented as a set of runtime extensions to the Lua language.

Homepage: http://www.lua.inf.puc-rio.br/luagravity/

I presented the talk entitled “Interactive applications for the Brazilian Digital TV”. The Brazilian standard uses an authoring language called NCL[2] that can be scripted with Lua for developing interactive applications. I developed the integration between the two languages during my MSc period at the Telemídia Lab[3].

The guy that would present the last talk didn’t show up and I was given the opportunity to speak about LuaGravity. It was good to see the reaction of a Lua aware audience and I could talk to some people about the project. I’m particularly interested in integrating LuaGravity with eLua[4] (also presented in the workshop).

[1]: http://www.lua.org/wshop09.html

[2]: http://www.ncl.org.br/index_en.php

[3]: http://www.telemidia.puc-rio.br

[4]: http://elua.berlios.de/

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/