Our great sponsors
- Appwrite - The open-source backend cloud platform
- Revelo Payroll - Free Global Payroll designed for tech teams
- InfluxDB - Collect and Analyze Billions of Data Points in Real Time
- Onboard AI - Learn any GitHub repo in 59 seconds
- SonarQube - Static code analysis for 29 languages.
-
This is absolutely one of my favorite patterns. I really like using it to build state machines. Each state has a constrained extension full of behaviors and a method you can use to transit to the next state that just scoops all the data into a new container with a different tag. A light extension of that pattern is to then use associated/nested types dependent on the tags to define other behaviors such as custom state associated with each point in the machine. Conversely, behaviors common to every state can be added via an extension as per usual. Here’s a big hairy TypeChecker written following this pattern with its implementation split across an entire modules’ worth of files. Each transition point from elaboration to type checking to type inference is neatly contained by the tag which uniquely determines the state carried at each point.
-
Yes, it is a false dichotomy to suggest one does not need tests because one has types. One needs both in systems of sufficient complexity. Even CompCert has a test suite, and it’s got a full formal proof of its own correctness!
-
Appwrite
Appwrite - The open-source backend cloud platform. The open-source backend cloud platform for developing Web, Mobile, and Flutter applications. You can set up your backend faster with real-time APIs for authentication, databases, file storage, cloud functions, and much more!
Related posts
- Recently I am having too much friction with the borrow checker... Would you recommend I rewrite the compiler in another language, or keep trying to implement it in rust?
- There is such thing called bugfree code.
- Proofs about Programs
- Is "my version" of quick-sort incorrect?
- What are some possible research questions on compiler construction