Colibri: The Fully Declarative And Turing-Complete Language Lurking Inside

Colibri: The Fully Declarative And Turing-Complete Language Lurking Inside Swift’s Type System

5 Likes

This is so interesting. What fantastic project, I am curious if it's fully type-system only if switch is being used (which is technically control flow). Regardless, distilling all the logic down to only switch statements is impressive. This was so fun to read thank you for sharing with us.

3 Likes

I wouldn't call pattern matching control flow. I"d describe it as value decoding. there is more to read: https://decodemeester.medium.com. In A New Coding Paradigm: Declarative Domain Programming | by Manuel Meyer | CodeX | Medium I walk the whole distance from model types via BDD/TDD to a full app architecture. all with the same principles. let me know, what you think if you find the time to read it.

1 Like

This is really fascinating to read and was kinda a cool mind puzzle to rethink how outcomes are procedurally and structurally generated outside of the typical if else paradigm we’re used to.

I will note that this paragraph is missing a ..

.state(to:.notStarted), 
.state(to:inProgress) & 
.state(to:.finished)

Should be

.state(to: .inProgress) & 

Just a minor thing. No biggie.

2 Likes

thanks, fixed.

Isn't it just a regular functional way of doing things through use of ADTs, functions and pattern matching? Basically something like this.
If not, then how it's different? :thinking:

There are some similarities, most notably the Algebraic (or Composable as Scott calls it) Type System of F# and Swift. I have not seen DSLs like in Colibri elsewhere. If you have, please link me to it.

One must define what is DSL then, for me it's languages limited to some domain, like HTML or SQL. With Colibri—what exactly is scoped domain?
Maybe I'm missing something completely, but for ML family of languages like Haskell, Ocaml or F# it's quite common to write features similar way, e.g. here is a small tutorial demo for Elm.

in Colibri's case a domain is a model like a model entity, a use case or a feature and app domain. each of those have there own small language to communicate. in models it is the change enum, in use cases the request and response enums and for feature and app domain (several features combined ) it is the message enum.