3 ms·

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:

by 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.
  - pron 10y ago
    Any plans on offering formal methods for Céu?
    - fsantanna 10y ago
      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 10y ago
        Temporal logic verification (via model checking, static analysis, test generation, runtime checks etc.)?
        fsantanna 10y ago
        That would be interesting. It seems to be feasible given the language semantics. We'll definitely investigate it.
fsantanna 10y ago
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 http://www.ceu-lang.org/chico/#ceu

by zzzcpan 10y ago

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.
- pron 10y ago
  Any plans on offering formal methods for Céu?
  - fsantanna 10y ago
    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 10y ago
      Temporal logic verification (via model checking, static analysis, test generation, runtime checks etc.)?
      - fsantanna 10y ago
        That would be interesting. It seems to be feasible given the language semantics. We'll definitely investigate it.

fsantanna 10y ago

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 http://www.ceu-lang.org/chico/#ceu