I spent several years' worth of weekends working on this, and I'm glad to see it here on Hacker News.
I started working on this problem when I learned about Lamping's algorithm for optimal lambda reduction [1]. He invented a beautiful algorithm (often referred to as his "abstract algorithm"), which uses fan-in and fan-out nodes to reduce lambda terms optimally (with optimal sharing). Unfortunately, in order to make it fully work, some fans needed to duplicate one another while others needed to cancel one another. To determine this correctly Lamping had to extend his abstract algorithm with several delimiter node types and many additional graph reduction rules. These delimiter nodes perform "bookkeeping", making sure the right fan nodes match. I was dissatisfied with the need for these additional nodes and rules. There had to be a better way.
My goal was to try to implement Lamping's abstract algorithm without adding any delimiter nodes, and to do it under the interaction net paradigm to ensure perfect confluence. I tried countless solutions, and finally Delta-Nets was born. Feel free to ask any questions.
I recently started building a programming language on top of Delta-Nets, called Pur (https://pur.dev/).
Author here. Other experts in this field have also used the term "lambda reduction", including Levy himself [1] and Lamping [2], both which are referenced in the Delta-Nets paper. "Lambda-reduction" is clearly an abbreviation of Lambda-calculi reduction.
Six weeks of six days (4 work days and 2 rest days) in a month would be better than four weeks of nine days (6 work days and 3 rest days) in my opinion.
This is awesome! It looks like a fantastic way to play with boolean logic and learn/teach how computers work. I love the ability to encapsulate circuits and abstract them into higher level components.
Nice article! I'm building a language (https://flame.run/) in Rust that aims to have WebGPU+GUI support built-in. I'm playing with refinement types, which you effectively described in the second-to-last section. I'm not familiar with contract-based languages (other than Solidity), but I think refinement types would allow specifying function parameter requirements in a similar fashion to what you described in your contract-based language section.
I'm building a language (https://flame.run) and trying a similar idea for imports. In my language there is no package manager. Files just import other files, locally or from URLs (like Deno). But, unlike Deno, I'd like to store the hashes of the imported files for security. I don't want to create a secondary file a la package.json, or even two files like go.mod/go.sum. So the idea I'm probably going with is that whenever you run/compile a program the tooling warns you and asks to insert the missing hashes of the imported files for you, inline.
Please see my comment here: https://news.ycombinator.com/item?id=46069564