fsantanna

Thank you! To install, `sudo` is not even required, so I'll change the default script. I understand that designing any kind of distributed consensus is somewhat disputable (if not pretentious), but I'm not convinced that client-side decisions are enough. For example, local reputation would not prevent posts from new users to be linked in the dependency graphs forever. Client rules can still override the network for posts that are not blocked. In fact, this reputation system is more about preventing abuse from new users and in some cases mistakes or hacked accounts from old users. I think there's still space for experimentation on global consensus besides PoS (S=something). In this particular system, reputation/consensus is local (per-topic) and depends on its own resources (posts) as well.

Only posts can farm reputation, the number of authors doesn't matter. To farm reputation from posts, you would need an automated post creation algorithm that passes the Turing test (or an algorithm that creates useful content for the community, which would be legitimate). Ultimately, authors that already have reputation decide which posts receive reputation. I believe that would be difficult for a small number of malicious authors to take control of the community trying to be smart, but I don't have any strong evidence though.

Hi, I'm the author of Freechains.

Any feedback is welcome.

Francisco

- Céu can embed blocks in C and call it directly

- C is more portable

- C is easier to generate

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.

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

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

You can download Esterel freely:

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_p...

Don't know about Lustre.

That would be interesting.

It seems to be feasible given the language semantics.

We'll definitely investigate it.

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?

> "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.

Thanks for the explanation, this is pretty accurate.

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

Yes, we can take advantage of all existing libraries in C/C++ for free.

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

- 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

Thanks, forgot to mention in the other comment that Céu is actually based on Esterel.

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.

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").

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.

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

Céu is a Esterel-based deterministic/synchronous/concurrent language:

http://www.ceu-lang.org

(I'm the author of Céu.)

Your impressions about Céu are very accurate, but I would like to add some remarks. There are three possible perspectives about the language: the "static", presented in the SenSys'13 paper; the "dynamic", presented in the Modularity'15 paper; and also the actual compiler publicly available.

The static version shares similar restrictions to Esterel, as you both pointed out. The dynamic version allows dynamic allocation inside lexical pools, keeping static memory management (no GC or "free"), but with possible unbounded memory usage. The actual compiler is even less restrictive and just gives warnings for unbounded loops, recursive calls, and so on.