Posts Tagged ‘Esterel’
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  at Sensys’11 last week. The 3-page summary submitted to the conference can be reached here.
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 loop abort RunSlowly when 15 Second; abort every Step do Jump || Breathe end every when 100 Meter; FullSpeed 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.