[ANN] d-Ceu: A dynamic reincarnation of Céu

[Francisco Sant'anna]

Hello,

After almost 5 years (!), I'm happy to announce the next release of Ceu:

https://github.com/fsantanna/dceu

----------

Ceu is a synchronous programming language that reconciles Structured Concurrency with Event-Driven Programming, extending classical structured programming with three main functionalities:

- Structured Concurrency:

    - A set of structured primitives to compose concurrent tasks (e.g., spawn, par-or, toggle).
    - A synchronous and deterministic scheduling policy, which provides predictable behavior and safe abortion of tasks.
    - A container primitive to hold dynamic tasks, which automatically releases them on termination.
- Event Signaling Mechanisms

    - An await primitive to suspend a task and wait for events.
    - A broadcast primitive to signal events and awake awaiting tasks.
- Lexical Memory Management

    - Even dynamic allocation is attached to lexical blocks.
    - Strict escaping rules to preserve structure reasoning.
    - Garbage collection restricted to local references only.

Ceu is inspired by Esterel and Lua.

Follows an extended list of functionalities:
    - Dynamic typing
    - Expression based (statements are expressions)
    - Stackless coroutines (the basis of tasks)
    - Restricted closures (upvalues must be explicit and final)
    - Deferred expressions (for finalization)
    - Exception handling
    - Dynamic collections (tuples, vectors, and dictionaries)
    - Hierarchical tuple templates (for data description with inheritance)

Ceu is in experimental stage. Both the compiler and runtime can become very slow.

----------

The general goals are the same, but switching to dynamic typing allowed me to bring modern features that were taking an eternity to complete.

I also removed the acute ´ from Ceu, which caused much confusion in the past.

Regards,

Francisco

[Job van der Zwan]

Congratulations on the release!

I see that you are using Kotlin? Is it the new host language? How are you enjoying it as a language?

Cheers,

Job

[Francisco Sant'anna]

On Fri, Feb 10, 2023 at 2:54 PM Job van der Zwan <j.l.van...@gmail.com> wrote:

I see that you are using Kotlin? Is it the new host language?

No. Just to implement the compiler, which still "cross-compiles" to C, which is still the host language.

 

How are you enjoying it as a language?

I see it as a drop-in replacement to Java with no negative tradeoffs.

Type inference, data classes, lambda syntax, etc.

[Francisco Sant'anna]

The manual:

- https://github.com/fsantanna/dceu/blob/main/doc/manual-out.md

A section about the design:

- https://github.com/fsantanna/dceu/blob/main/doc/manual-out.md#design

[Job van der Zwan]

On Thursday, 2 March 2023 at 16:46:10 UTC+1 Francisco Sant'Anna wrote:

The manual:

- https://github.com/fsantanna/dceu/blob/main/doc/manual-out.md

A section about the design:

- https://github.com/fsantanna/dceu/blob/main/doc/manual-out.md#design

Nice, thank you! The source code was actually surprisingly accessible despite my lack of familiarity, but this is even better :)
 

[Job van der Zwan]

"Ceu respects the lexical structure of the program also when dealing with dynamic memory allocation. Every dynamic value is attached to the block in which it was first assigned and cannot escape it in further assignments or as return expressions. This is valid not only for collections (tuples, vectors, and dictionaries), but also for closures, coroutines, and tasks. This restriction ensures that terminating blocks (and consequently tasks) deallocate all memory at once. More importantly, it provides static means to reason about the program. To overcome this restriction, Ceu also provides an explicit move operation to reattach a dynamic value to an outer scope."

Would it be fair to say that this was inspired by Rust, but instead of a borrow checker you use a much simpler "has to be moved to a higher scope explicitly" approach? I like how straightforward the design is, and it seems quite easy to reason about. Is it also easier to implement?

A peek operation vec[=] sets or gets the last element of a vector. The push operation vec[+] adds a new element to the end of a vector. The pop operation vec[-] gets and removes the last element of a vector.

I really love this syntax, by the way. Especially vec[=] since represents such a common operation that's often a bit painful to write in other languages. If we had a deque collection I could imagine extending it to unshift and shift operators as deque[+..] and deque[-..]

[Francisco Sant'anna]

On Fri, Mar 3, 2023 at 3:33 PM Job van der Zwan <j.l.van...@gmail.com> wrote:

"Ceu respects the lexical structure of the program also when dealing with dynamic memory allocation. Every dynamic value is attached to the block in which it was first assigned and cannot escape it in further assignments or as return expressions. This is valid not only for collections (tuples, vectors, and dictionaries), but also for closures, coroutines, and tasks. This restriction ensures that terminating blocks (and consequently tasks) deallocate all memory at once. More importantly, it provides static means to reason about the program. To overcome this restriction, Ceu also provides an explicit move operation to reattach a dynamic value to an outer scope."

Would it be fair to say that this was inspired by Rust, but instead of a borrow checker you use a much simpler "has to be moved to a higher scope explicitly" approach?

Not really.

I believe it's more a consequence of the "structured approach" of synchronous languages.

In the past, we already had this behavior for "organisms", later "code/await", now "tasks".

Now it is also extended to collections, which we didn't support at all in the past.

I'm not a Rust programmer, but IIUC heap values can move between scopes with no restrictions:

fn f () -> String {
    let s = String::from("hello");  // heap allocated
    return s;                       // escapes w/ no restrictions
}
fn main () {
    let s = f();
    println!("{}, world!", s);
}

Ceu is more about this idea of "structured reasoning", which extends to heap values ("more importantly, it provides static means to reason about the program").

The example above would require a "move(s)".

I'm not a believer of Rust for event-driven applications because the event loop pushes all state to become ref-counted globals, never actually relying on ownership drops to free memory.

Not to mention how you need to track pointers as integer indexes...

 

I like how straightforward the design is, and it seems quite easy to reason about. Is it also easier to implement?

Ceu is dynamic, so it is much easier: each dynamic value carries its scope depth, which is checked in assignments at runtime.

In a hypothetical static Ceu, I believe it would be at least as hard as tracking unique references. I gave up for a while.

 

A peek operation vec[=] sets or gets the last element of a vector. The push operation vec[+] adds a new element to the end of a vector. The pop operation vec[-] gets and removes the last element of a vector.

I really love this syntax, by the way. Especially vec[=] since represents such a common operation that's often a bit painful to write in other languages. If we had a deque collection I could imagine extending it to unshift and shift operators as deque[+..] and deque[-..]

Let's see.