From theorem to code

In the paper	In the code
The context	an object
Registering an effect	a method call
A piece instance	a struct with its fields
The stack of inverses from chapter three	the field that removes it

Hot reload with nothing to configure

There is a practical application that shows the advantage well.

When you change a file while developing, the system can replace that module without restarting the process. That already exists in other tools, but it usually requires the programmer to mark by hand which modules can be replaced and which cannot.

Here it is not needed, and the reason is structural: every piece already delimits everything it installed, so replacing it means discarding it and mounting it again.

• Phase 1 Accept Decide which modules can be replaced
• Phase 2 Detect Work out which pieces they make stale
• Phase 3 Reload Discard and mount again, transactionally

The case study

The chat bot framework mentioned at the start has been running on Cordis for four years and has accumulated more than four thousand community plugins.

What it validates is not only the scale. The framework contributes nothing but the vocabulary of its own domain. Everything else, the loading of pieces, the shared context, the events and the effects that undo themselves, comes from the same basic mechanisms.

And the same model works in a completely different environment: its web console is a separate application built with those mechanisms, this time on top of browser pieces.

The sentence that made me trust the rest

An 88 page paper with formal proofs that writes that about its own empirical evidence is doing its job well.