This timing additions to a language is also at the core of imperative synchronous programming languages like Este rel, Céu or Blech.

A way to implement coroutines in C is via protothreads. I admit that they are a bit hacky - but you can get quite far with them. I used them to implement an Esterel/Blech like environment: https://github.com/frameworklabs/proto_activities

Protothreads are amazing, but really expose you to a lot of subtle bugs. I would not recommend them for any new projects if something like async rust or an RTOS are options.

Yeah this was exactly my conclusion at the time. It's a cool trick but I just don't think I wanna write a serious system in a special half-language like that.

In `proto_activities` this blinking would look like this:

  pa_activity (Blinker, pa_ctx_tm(), uint32_t onMs, uint32_t offMs) {
    pa_repeat {
      turn_on_LED();
      pa_delay_ms (onMs);
  
      turn_off_LED();
      pa_delay_ms (offMs);
    }
  } pa_end

Here the activity definition automatically creates the structure to hold the pc, timer and other variables which would outlast a single tick.

A similar approach, but rooted in the idea of synchronous languages like Esterel or Blech:

https://github.com/frameworklabs/proto_activities

This is Céu[0] erasure! ... I'm joking, I'm joking, although I do think it deserves a mention.

Seriously though, neat library! It took me a moment to realize that everything with a pa_ prefix is a macro, for the dumb reason of being used to only see those in ALL_CAPS. Not saying you can't use lower-case macros but I think a short sentence mentioning it before the demo code, and with a "see the protothread under the hood page[1] for an explanation of how it generally works" would help a lot with demystifying the code for people unfamiliar with the concepts involved.

[0] https://ceu-lang.github.io/

[1] https://dunkels.com/adam/pt/expansion.html

Proto-Activities have this context to store the state in the caller.

https://github.com/frameworklabs/proto_activities

Somewhat related to Fibres are the Trails of synchronous reactive programming languages. Both allow efficient logical concurrency based on cooperative scheduling. The nice thing with Trails is that the scheduling can be determined by the compiler by extracting dependencies from the synchronous reactive program thus increasing determinism of your app.

Drakon uses Silhouettes to show code linearly and abstracted at the same time:

https://drakon.tech/read/silhouette

Right, imperative synchronous programming simplifies real time processing a lot.

Somehow it does not get the attention it should, which is IMHO due to the fact that it is not available in common programming languages.

This is why I tried to create DSLs for C and Swift so that more people could potentially play around with that.

https://github.com/frameworklabs/proto_activities

Oooh, this is delightful, thank you for sharing!

The magic source of Contiki is IMHO the use of protothreads as a lightweight concurrency system. Protothreads can also be used to implement synchronous programming models - like this one: https://github.com/frameworklabs/proto_activities

This paper: https://past.date-conference.com/proceedings-archive/2017/py... is on Sequentially Constructive Synchronous Concurrency which is also the base for the synchronous language Blech (https://www.blech-lang.org/)