The Synchronous Blog

A blog about reactive programming languages.

Posts Tagged ‘Esterel

“Céu: Embedded, Safe, and Reactive Programming”

with one comment

We have published a technical report entitled “Céu: Embedded, Safe, and Reactive Programming”.

Enjoy the reading!


Céu is a programming language that unifies the features found in dataflow and imperative synchronous reactive languages, offering a high-level and safe alternative to event-driven and multithreaded systems for embedded systems.

Céu supports concurrent lines of execution that run in time steps and are allowed to share variables. However, the synchronous and static nature of Céu enables a compile time analysis that can enforce deterministic and memory-safe programs.

Céu also introduces first-class support for “wall-clock” time (i.e. time from the real world), and offers seamless integration with C and simulation of programs in the language itself.

The Céu compiler generates single-threaded code comparable to handcrafted C programs in terms of size and portability.

Table of Contents:

  1. Introduction
  2. The Language Céu
    1. Parallel compositions
    2. Internal events & Dataflow support
    3. Wall-clock time
    4. Integration with C
    5. Bounded execution
    6. Determinism
    7. Asynchronous execution
    8. Simulation in Céu
    9. GALS execution
  3. Demo applications
    1. WSN ring
    2. Arduino ship game
    3. SDL game simulation
  4. Implementation of Céu
    1. Temporal analysis
    2. Memory layout
    3. Gate allocation
    4. Code generation
    5. Reactive execution
    6. Evaluation
  5. Related work
    1. Synchronous model
    2. Asynchronous model
  6. Conclusion

A “down to earth” reactive language: Céu

leave a comment »

It has been more than one year since my last blog post. The reason is the direction I took two years ago, in the beginning of my PhD, switching from LuaGravity to something more grounded.

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.


Written by francisco

November 15, 2011 at 11:24 pm

Paper accepted.

leave a comment »

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.


Imperative Reactivity

with 2 comments

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( 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:

LINK(,  animation.changeDirection)
LINK(, animation.changeDirection)
LINK(,    animation.changeDirection)
LINK(,       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

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

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

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

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

    obj.x = obj.x()                  -- stay here
    obj.y = obj.y() - S(obj.speed)   -- move up

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.

Written by francisco

October 7, 2008 at 8:31 pm

Esterel: A Unique Language

with one comment

Esterel was developed in the early ’80s in France in parallel with other two languages, Lustre and Signal. These, together with Statecharts, are considered the first synchronous languages.
Esterel found its niche in control intensive real-time applications and evolves as a standard, with several implementations.

Unlike all synchronous languages, Esterel is the only one to provide an imperative style of programming. This is kind of surprising for me considering the high popularity of imperative languages.
Why there’s no attempts to create new languages based on the Esterel foundations?

I cannot argue about functional vs imperative style of programming, but I do feel more comfortable with the latter (most people do), and they will be around for the next years.
I like the Lua approach, which seems to favor imperative style but concisely support most functional features without bloat.

The example below, written in Esterel, implements the basic training for an athlete:

module Runner:
    input  Second, Morning, Step, Meter, Lap;
    output ...; % not used
    every Morning do
                abort RunSlowly when 15 Second;
                    every Step do
                        Jump || Breathe
                    end every
                when 100 Meter;
            each Lap
        when 2 Lap
    end every
end module

Esterel authors argue that, following this imperative style, programs are almost software specifications given as recipes in natural English.

The communication in Esterel is made through broadcast input and output signals.
The synchronous preemption constructs (every do, loop each, abort when, etc) are the heart of the language.
LuaGravity provides constructs based on them, which I consider even more useful than the functional facilities.

Written by francisco

September 29, 2008 at 11:01 pm