[zzzcpan]

Was there a particular problem you were trying to solve by creating Ceu? Or was it just to learn things about compilers?

EDIT: found the answer in the paper: "Despite the continuous research in facilitating programming WSNs, most safety analysis and mitigation efforts in concurrency are still left to developers, who must manage synchronization and shared memory explicitly. In this paper, we present a system language that ensures safe concurrency by handling threats at compile time, rather than at runtime."

[pron]

I'm not the language's creator, but I assume that part of the goal was to bring synchronous programming to the mainstream. Synchronous programming languages are well known in the safety-critical hard realtime world. They're based on a mathematical theory that (as opposed to pure-functional programming) embraces interaction and concurrency, which makes them very suitable for interactive applications (whereas compilers are the natural domain for pure-FP). In addition, synchronous languages are currently the most amenable languages to formal verification. These two reasons are why they're popular and successful in the domain I mentioned. Also, synchronous languages naturally support styles of programming (under research) that are intended to be more natural, and facilitate correct code (in addition to the formal-method-friendliness), such as behavioral programming[1].

BTW, Eve is another synchronous language, although a declarative rather than an imperative one like Céu. It's great to see those time-tested and well-studied ideas finally break out of the safety-critical realtime world.

[1]: http://www.wisdom.weizmann.ac.il/~bprogram/more.html

[fsantanna]

> "part of the goal was to bring synchronous programming to the mainstream"

This was not the original academic goal, but it is now.

We want to offer an imperative alternative to program reactive systems.

[pron]

Any plans on offering formal methods for Céu?

[fsantanna]

Some colleagues are working on an operational semantics of the language (based on the one in the thesis). This will allow us to prove some claims (e.g., reaction termination, bounded memory). Then, we may think about something else. Anything more specific in mind?

[pron]

Temporal logic verification (via model checking, static analysis, test generation, runtime checks etc.)?

[fsantanna]

That would be interesting.

It seems to be feasible given the language semantics.

We'll definitely investigate it.

[fsantanna]

Thanks for the explanation, this is pretty accurate.

[fsantanna]

Yes, the problem on how to handle events in soft real-time applications with concurrent activities that affect each other. We initially targeted constrained embedded systems and came with the following design decisions:

- Safe and seamless integration with C (everything in ES uses C). Approach: source-to-source compiler + finalization mechanisms.

- Allow shared memory concurrency (typical in ES with I/O ports and low-level manipulation). Approach: synchronous concurrency + full determinism.

- Small overhead (we target 8-bit micro-controllers). Approach: single-threaded implementation, lexical memory management (no GC).

After investigating the synchronous languages from the '80s (Esterel, Lustre, Signal), we came to the conclusion that we wanted something in the line of Esterel.

The thesis and papers [1] discuss the design decisions in extent.

[1]: http://www.ceu-lang.org/chico/#ceu