It would be helpful if you could provide a high-level explanation of what "Structured Reactive Programming" means and what problem you are trying to solve with current solutions? How is it different from current reactive environments?
Synchronous: reactions run to completion, i.e., there's no implicit preemption or real parallelism (this avoids explicit synchronization: locks, queues, etc)
Structured: programs use structured control mechanisms, such as "await" (to suspend a line of execution), and "par" (to combine multiple awaiting lines of execution)
Structured programming avoids deep nesting of callbacks letting you write programs in direct/sequential style. In addition, when a line of execution is aborted, all allocated resources are safely released.
In comparison to FRP/dataflow, it is more imperative supporting sequences/loops/conditionals/parallels. The notion of (multiple) program counter is explicit. Also, everything is lexically scoped, there's no GC involved.
In comparison to promises/futures, it provides lexical parallel constructs, allowing the branches to share local variables and, more importantly, supporting safe abortion of code (with the "par/or").
Yes in theory. But in practice the language includes "async" support so you can guard these few operations that may take long. Like in a functional language you assume everything is pure unless marked to have side-effects, here you assume every reaction is instant unless is something that has to be explicitly "awaited" for. It's a pretty clean model.
Another way of thinking about this (also mentioned in the docs somewhere) is that Ceu "pretends" that any reactive code finishes infinitely fast, similar to how garbage collected languages "pretend" that computers have infinite memory.
Neither truly does, of course, but the idea is that for the vast majority of situations where either type of language is used, that's a good enough approximation, letting you vastly simplify the problem that you're solving.
Thank you!
I'm enthusiastic with the Arduino binding, it provides a friendly way to handle
events without much bloat.
These characteristics fit well in this domain of non specialists programming
constrained embedded systems.
I wrote in Lua the source-to-source compiler that takes a ".ceu" and generates a ".c" (the code is a single-threaded state machine), which is then compiled with gcc.
The compiler is slow, but not the final binary.
We wrote a paper [1] that compares flash,RAM,CPU usage from Céu vs hand-written event-driven code in C.
The differences are negligible.
For those who are interested in synchronous reactive programming and speak French, Gérard Berry gave lectures about it (and time-related topics in general) at Collège de France, along with other teachers including M. Pouzet. Videos are publicly available, check out:
1. Dynamic abstractions with lexical scope (vs. mostly static language). You can dynamically spawn code into a lexically-scoped pool.
2. Internal/fine-grained determinism (vs. external determinism). All statements execute in a deterministic order. E.g., if you have two printf's in parallel awaking from the same event, they will execute in lexical order.
3. Safe integration with C. When calling a C function that returns a pointer (e.g., "malloc"), Céu forces you to write a finalization clause (in which you can call "free"). If this code is somehow aborted, the "free" is called automatically.
4. Timers as first-class events (e.g., "await 1s"). Besides the convenience, Céu adjusts timers in sequence, e.g., if a first timer awakes a little bit late (due to system overhead), the timer in sequence will compensate.
5. Internal events are stack-based (vs. queue based). This allows co-routine-like functionality, resumable exceptions, and some other mechanisms.
6. Event-based logical notion of time (vs. tick based). A single event can occur at a logical time (related to #2).
[EDIT] Didn't mention that these are "advantages" depending on the context. Esterel targets hardware synthesis and also hard real-time systems. Dynamic abstractions might be irrelevant, fine-grained/sequential determinism in hardware might be inefficient, a tick is closer to a hardware clock, etc...
In comparison to Lustre:
Very different programming mindset.
IIRC, in Lustre you define equations and the system is responsible for keeping them up-to-date/correct.
It is a data-flow language (vs control-flow), closer to FRP than Céu/Esterel.
Céu looks really similar to Esterel. The thesis (http://www.ceu-lang.org/chico/ceu_phd.pdf) has a section titled "III.7 Differences to Esterel". (edit: removed explanations, the other comment is more detailed).
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."
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.
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?
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.
I've been trying to learn more about synchronous programming languages for a while now. Will definitely look into this.
Does anyone know how I could get my hands on Lustre or Esterel? They are not freely available, or are they? Also any good books or resources are very much appreciated.
Thank you! I'm actually working on my own synchronous language, but it's more in line with Lustre than Esterel. Synchronous dataflow with soft real-time goals. If it starts to look like something decent I'll put it on github.
Since you're interested in the implementation of synchronous languages you could also take a look at Quartz [1]. Their book is a fantastic resource about the topic.
Kudos for the work! The intro video is really nice (pro tip: it is perfectly watchable at 1.25x (or even 1.5x) speed — thanks, YouTube speed settings!)
Although Céu is about 5 years now, this is the first time I post to "Show HN".
In this new version, we are trying to surpass the academic fences with a more polished work (docs, build, etc).
All feedback is welcome.
Francisco