6 ms·

Show HN: Céu, Structured Synchronous Reactive Programming

107 points by fsantanna 10y ago

fsantanna 10y ago
Hi, I'm the author of the programming language Céu. 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
- pizza 10y ago
  https://github.com/fsantanna/ceu-arduino https://github.com/fsantanna/ceu-arduino That's pretty cool!
  - fsantanna 10y ago
    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.
    - vanderZwan 10y ago
      Perhaps it's a good use-case to highlight on the main page of Ceu?
- teleclimber 10y ago
  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?
  - fsantanna 10y ago
    Thank you, I will improve the page. In summary: Reactive: code executes in reactions to events 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").
    - jessaustin 10y ago
      Synchronous: reactions run to completion, i.e., there's no implicit preemption or real parallelism Does this mean a program will hang if e.g. disk or network access takes too long?
      - hisham_hm 10y ago
        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.
      - fsantanna 10y ago
        External calls in C require an underscore (e.g., "_printf") to be easily trackable as possibly unsafe. Also, at some point in the code (e.g., after you include your libraries), one can disable these calls with a directive. But typically, one will use bindings for asynchronous libraries, such as libuv (https://github.com/fsantanna/ceu-libuv https://github.com/fsantanna/ceu-libuv).
- zerr 10y ago
  Why did you choose Lua as the implementation language?
  - fsantanna 10y ago
    - Dynamic typing for fast prototyping. The compiler is full of dynamic tricks for testing, stripping parts of it, etc. - LPeg support [1]. PEGs are great! - The creator of Lua was my advisor since undergrad. :) (Which means that I program in Lua for a long time...) http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html
    - zerr 10y ago
      And this means that the performance is not the first (or second) reason to use Ceu, right? In other words, is it somewhat slow?
      - fsantanna 10y ago
        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. [1] http://www.ceu-lang.org/chico/ceu_sensys13_pre.pdf http://www.ceu-lang.org/chico/ceu_sensys13_pre.pdf
        fenollp 10y ago
        Why not plug into LLVM? Just generate an LLVM backend.
        fsantanna 10y ago
        - Céu can embed blocks in C and call it directly - C is more portable - C is easier to generate
- tluyben2 10y ago
  Thanks for posting it. And for sticking with it that long. It is something I will one time do but I did not try enough languages yet to forge my own.
- agumonkey 10y ago
  What were your influences ? other "synchronous" languages like lucid ?
  - fsantanna 10y ago
    The main influence is Esterel, but we visited most synchronous literature (including Lucid). We also take the syntax from Pascal/Lua and the basic types and expressions from C (due to source compatibility).
    - agumonkey 10y ago
      Thanks a lot. We had a class in esterel in college, but it flew over my head at the time, sadly. Time to revisit the whole thing. May I ask you if you have some favorite references/papers about the subject ?
      - fsantanna 10y ago
        The early papers about Esterel and the synchronous model, e.g.: - Gérard Berry: "Real time programming: Special purpose or general purpose languages" For the semantics, I like this paper focusing on abortion (for me, the most expressive construct of synchronous languages): - Gérard Berry: "Preemption in Concurrent Systems" There's also a well-known survey: - Albert Benveniste: "The synchronous languages 12 years later" This one is about bridging the gap between synchronous and asynchronous, something like Esterel+CSP: - Gérard Berry: "Communicating reactive processes" For a modern take (besides Céu), check ReactiveML: - Louis Mandel: "ReactiveML: a reactive extension to ML" You can also search for papers from professors Stephen A. Edwards and Reinhard von Hanxleden which still work actively on the subject.
        catwell 10y ago
        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: http://www.college-de-france.fr/site/gerard-berry/course-2012-2013.htm http://www.college-de-france.fr/site/gerard-berry/course-201... http://www.college-de-france.fr/site/gerard-berry/course-2013-2014.htm http://www.college-de-france.fr/site/gerard-berry/course-201... (In 2014 - 2016 he moved on to program proofs, which may also interest some of you.)
hisham_hm 10y ago
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!)
ratstew 10y ago
What are the advantages of Céu over other synchronous programming languages such as Esterel and Lustre?
- fsantanna 10y ago
  In comparison to Esterel: 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.
  - ratstew 10y ago
    The C integration aspect sounds really neat, especially for writing concurrent code on the Arduino! Thanks for the detailed explanation.
    - fsantanna 10y ago
      Yes, we can take advantage of all existing libraries in C/C++ for free.
zzzcpan 10y ago
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 10y ago
  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 http://www.wisdom.weizmann.ac.il/~bprogram/more.html
  - fsantanna 10y ago
    Thanks for the explanation, this is pretty accurate.
  - fsantanna 10y ago
    > "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.
AlexanderDhoore 10y ago
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.
- fsantanna 10y ago
  You can download Esterel freely: http://www-sop.inria.fr/esterel-org/files/Html/Downloads/Downloads.htm http://www-sop.inria.fr/esterel-org/files/Html/Downloads/Dow... (AFAIK, it is not open source though.) [EDIT] For documentation, see "The Esterel Language Primer": http://www.rw.cdl.uni-saarland.de/~kaestner/es0203/esterel_primer.pdf http://www.rw.cdl.uni-saarland.de/~kaestner/es0203/esterel_p... Don't know about Lustre.
  - AlexanderDhoore 10y ago
    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.
    - ratstew 10y ago
      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. [1] http://www.averest.org http://www.averest.org
flippyhead 10y ago
Great to see this here. I love Ceu. It's a joy to use for the Arduino.
talles 10y ago
Just a bit of trivia: "lua" means "moon" and "céu" means "sky" in Brazilian Portuguese.

107 points by fsantanna 10y ago

Hi, I'm the author of the programming language Céu. 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

pizza 10y ago
https://github.com/fsantanna/ceu-arduino https://github.com/fsantanna/ceu-arduino That's pretty cool!
- fsantanna 10y ago
  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.
  - vanderZwan 10y ago
    Perhaps it's a good use-case to highlight on the main page of Ceu?
teleclimber 10y ago
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?
- fsantanna 10y ago
  Thank you, I will improve the page. In summary: Reactive: code executes in reactions to events 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").
  - jessaustin 10y ago
    Synchronous: reactions run to completion, i.e., there's no implicit preemption or real parallelism Does this mean a program will hang if e.g. disk or network access takes too long?
    - hisham_hm 10y ago
      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.
    - fsantanna 10y ago
      External calls in C require an underscore (e.g., "_printf") to be easily trackable as possibly unsafe. Also, at some point in the code (e.g., after you include your libraries), one can disable these calls with a directive. But typically, one will use bindings for asynchronous libraries, such as libuv (https://github.com/fsantanna/ceu-libuv https://github.com/fsantanna/ceu-libuv).
zerr 10y ago
Why did you choose Lua as the implementation language?
- fsantanna 10y ago
  - Dynamic typing for fast prototyping. The compiler is full of dynamic tricks for testing, stripping parts of it, etc. - LPeg support [1]. PEGs are great! - The creator of Lua was my advisor since undergrad. :) (Which means that I program in Lua for a long time...) http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html
  - zerr 10y ago
    And this means that the performance is not the first (or second) reason to use Ceu, right? In other words, is it somewhat slow?
    - fsantanna 10y ago
      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. [1] http://www.ceu-lang.org/chico/ceu_sensys13_pre.pdf http://www.ceu-lang.org/chico/ceu_sensys13_pre.pdf
      - fenollp 10y ago
        Why not plug into LLVM? Just generate an LLVM backend.
        fsantanna 10y ago
        - Céu can embed blocks in C and call it directly - C is more portable - C is easier to generate
tluyben2 10y ago
Thanks for posting it. And for sticking with it that long. It is something I will one time do but I did not try enough languages yet to forge my own.
agumonkey 10y ago
What were your influences ? other "synchronous" languages like lucid ?
- fsantanna 10y ago
  The main influence is Esterel, but we visited most synchronous literature (including Lucid). We also take the syntax from Pascal/Lua and the basic types and expressions from C (due to source compatibility).
  - agumonkey 10y ago
    Thanks a lot. We had a class in esterel in college, but it flew over my head at the time, sadly. Time to revisit the whole thing. May I ask you if you have some favorite references/papers about the subject ?
    - fsantanna 10y ago
      The early papers about Esterel and the synchronous model, e.g.: - Gérard Berry: "Real time programming: Special purpose or general purpose languages" For the semantics, I like this paper focusing on abortion (for me, the most expressive construct of synchronous languages): - Gérard Berry: "Preemption in Concurrent Systems" There's also a well-known survey: - Albert Benveniste: "The synchronous languages 12 years later" This one is about bridging the gap between synchronous and asynchronous, something like Esterel+CSP: - Gérard Berry: "Communicating reactive processes" For a modern take (besides Céu), check ReactiveML: - Louis Mandel: "ReactiveML: a reactive extension to ML" You can also search for papers from professors Stephen A. Edwards and Reinhard von Hanxleden which still work actively on the subject.
      - catwell 10y ago
        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: http://www.college-de-france.fr/site/gerard-berry/course-2012-2013.htm http://www.college-de-france.fr/site/gerard-berry/course-201... http://www.college-de-france.fr/site/gerard-berry/course-2013-2014.htm http://www.college-de-france.fr/site/gerard-berry/course-201... (In 2014 - 2016 he moved on to program proofs, which may also interest some of you.)

hisham_hm 10y ago

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!)

ratstew 10y ago

What are the advantages of Céu over other synchronous programming languages such as Esterel and Lustre?

fsantanna 10y ago
In comparison to Esterel: 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.
- ratstew 10y ago
  The C integration aspect sounds really neat, especially for writing concurrent code on the Arduino! Thanks for the detailed explanation.
  - fsantanna 10y ago
    Yes, we can take advantage of all existing libraries in C/C++ for free.

zzzcpan 10y ago

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 10y ago
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 http://www.wisdom.weizmann.ac.il/~bprogram/more.html
- fsantanna 10y ago
  Thanks for the explanation, this is pretty accurate.
- fsantanna 10y ago
  > "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.

AlexanderDhoore 10y ago

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.

fsantanna 10y ago
You can download Esterel freely: http://www-sop.inria.fr/esterel-org/files/Html/Downloads/Downloads.htm http://www-sop.inria.fr/esterel-org/files/Html/Downloads/Dow... (AFAIK, it is not open source though.) [EDIT] For documentation, see "The Esterel Language Primer": http://www.rw.cdl.uni-saarland.de/~kaestner/es0203/esterel_primer.pdf http://www.rw.cdl.uni-saarland.de/~kaestner/es0203/esterel_p... Don't know about Lustre.
- AlexanderDhoore 10y ago
  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.
  - ratstew 10y ago
    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. [1] http://www.averest.org http://www.averest.org

flippyhead 10y ago

Great to see this here. I love Ceu. It's a joy to use for the Arduino.

talles 10y ago

Just a bit of trivia: "lua" means "moon" and "céu" means "sky" in Brazilian Portuguese.