It’s completely unclear to me what this means. The literal meaning is obviously wrong, because attaching a tree to a root that already has two child nodes would result in a ternary node, but apparently all trees in tree calculus are binary.
But what I believe was meant by the above was: "delta E1 E1" creates a new "reduction tree" (my own made up term) with E1 being the left child of this new root node, and E2 being the right child of this new root node - and which then begins applying the reduction on this newly constructed tree.
https://olydis.medium.com/a-visual-introduction-to-tree-calc...
Overall the concept seems pretty interesting - and it's nice to see someone come up with something both novel in the space and at the same time seemly "applicable".
I happened to read this link [1], so that's what I'm basing it off of. Also note, I don't know this at all so I may be flat our wrong, but hopefully this saves someone some time in getting a leg up on the right path. I would recommend glancing at the image at the top of that link for reference to follow along with my interpretation.
To me it overall seems like similar to a lisp focused on binary trees. There are rules 0a, 0b, 1, 2, 3a, 3b, 3c. And the concept is actually pretty simple. Rules 0 are construction rules. Rules 1 & 2 are combinators. And rule 3 is pattern matching which allows for reflection / acting on the shape of code (according to the docs).
First I think of there being 3 main constructions (and via analogy I'll use lisp terms even though this clearly is not lips and will not directly translate, but I think that will make communication easier rather than using unfamiliar terms).
Being a binary tree there are 3 main basic shapes. There is nil/false/empty that is represented by a single node. There is a "boxed expression" and there is a "paired expression". (in the diagram on the link w,x,y,z ... represent "unknown" expressions or maybe arguments if you want to think of them that way). '@' is used as the "apply" operator, but I'm going to call it "cons" even though it is not the "cons" from lisp.
Here is my view:
Construction Rules: 0a - If I cons false/nil with an unknown expression what do I get? i.e. what is "(cons 'nil z)", where z is an unknown expression? The answer is (nil . z) What I'll call a boxed expression.
0b - If I cons a "boxed expression" with an unknown expression what do I get? What is "(cons ('nil . y) z)"? Answer: a boxed pair: (y . z).
1 - [Note this rule does double duty and starts a new pattern that's kinda cool]. So continuing the pattern, if I cons a boxed pair with an unknown expression (cons (x . y) z) what do I get? Well it depends on the shape of the boxed pair. Specifically what is the shape of x? If it's 'nil then apply rule 1. (cons ('nil . y) z)) results in y.
Detour, it turns out (looking from the the perspective of the y and z, and 'cons' being a operator/combinator that this just happens to also be the 'K' combinator.
2 - So in this same boxed pair from above (cons (x . y) z), we said apply rule 1 if x is 'nil. But we've had consistent pattern (nil, boxed expr, paired expr) here so let's follow it now on the shape of x. So if x isn't 'nil, but is instead a boxed expression (nil . x) then use rule 2. Or to be explicit: (cons ((nil . x) . y) z) reduces to (cons (cons x z) (cons y z)). Here it is helpful to think of cons as "apply" as they define it and not my made-up 'cons', because then it's easy to see that this is the S combinator. Ie (apply (apply x z) (apply y z)).
3 - Ok so we have one stage left of our pattern for (cons (x . y) z). We said if x is 'nil you get rule 1. If x is a boxed expression, you get rule 2. And so if x is a paired expression, what do you get? Well you get a flavor of rule 3. Which flavor of rule 3? Well it depends on the shape of z. And if you've been following there are 3 choices for the shape of z. The same 3, nil, boxed expression and paired expression. You'll also note that this is the only time we'd have transformations depend on anything in z (the second argument to cons). Up until now z has always been a blackbox and had no affect on our rules - the first arg to cons always decided what we did. If you think of z as the data argument to cons and the first arg to cons being the code, this is allowing the code we execute to structurally depend on the data/argument. Ie this is your functional pattern matching behavior.
So let's walk through them, but where we left off we said in (cons (x . y) z), x could be nil and we get rule 1. x could be a boxed expression and we get rule 2. And if x is a paired expression we get rule 3. So a paired expression replacing the unknown x above looks like (cons ((w . x) . y) z).
[Note you can skip: To be consistent with the image in the link I've reused the letter 'x', but the x in (cons ((w . x) . y) z) is not the x in (cons (x . y) z). The 'x' in (cons (x . y) z) is equivalent to (w . x) in the (cons ((w . x) . y) z). Think hygienic syntax replacement for my own convenience. You can also ignore this whole bracked aside if it didn't make sense.]
Continuing rule 3, a paired expression replacing the unknown x above looks like (cons ((w . x) . y) z). Whether you apply rule 3a, 3b or 3c depends on the shapw of the "argument" z. If z is nil (or a base case like 0), you get the fixed expression 'w'. If z is a boxed expression (nil . u), you get (cons x u), and if it's a paired expression (u . v) you get (cons (cons y u) v). Ignoring the details, it will conditionally apply the "code" w, x or y to the argument z, depending on the shape of z. In my view that is essentially equivalent to functional programming style pattern matching - they describe it as reflection.
Overall it's a pretty cool system. 3 "basic shapes". A few basic construction rules, 2 combinators and a case for pattern matching. In my view they have an operator that combines cons and apply in an elegant way, and can do pattern matching on it. It seems to really get to the essence of a lot of ideas in the space and very concisely without many assumptions or overhead.
https://olydis.medium.com/a-visual-introduction-to-tree-calc...
> f = λa λb concat ["Hello ",a," ",b,"!"] > f "Jane" "Doe" Hello Jane Doe!
then,
> g = f "Admiral" > invert g "Hello Admiral Alice!" Alice
The inversion is really cool, e.g.
> f = λa λb concat ["Hello ", a, " ", b, "!"]
> f "Jane" "Doe"
Hello Jane Doe!
> g = f "Admiral"
> invert g "Hello Admiral Alice!"
AliceSee Barry’s post https://github.com/barry-jay-personal/blog/blob/main/2024-12... for more discussion.
He's really into the graphical representation of Turing machines and multiway Turing machines.
The first chapter is so completely self-aggrandizing about how this book will change your life and the world and the entirety of science and mathematics and you should feel lucky for reading it.
The cellular automata stuff is pretty cool, but I don't feel like it lived up to the hype of the first chapter.
Ok. But what is it?
The Tao giveth △ (false)
△ gives △ △ (true)
△(△, △) giveth rise to all things computable
(just kidding, I am totally lost to this)
[1] or not pure maths anyway. It's applied maths like all computer science.
It's like they had the idea of marketing this like a software project, not realizing that most front pages of software projects are utter bunk as well. It introduces terminology and syntax with no motivation or explanation.
Even once trying to get into "Quick Start" and "Specification" I was still mystified as to what it is or why I should want to play with it, or care. I had to go to the link mentioned upthread to get any sense of what this was or how it worked.
I think it's just badly written.
That being said, what seems to be proposed is a structure and calculus that are an alternative to lambda-calculus. The structures, as you can probably guess from the picture, are binary trees, ostensibly unlabeled except that there is significance to the ordering of the children. The calculus appears to be rules about how trees can be "reduced", and there is where the analogy to lambda calculus comes in.
Hopefully someone who actually knows this stuff can see whether I managed to get all that right – because I promise you, none of that understanding came from the website.
https://github.com/barry-jay-personal/tree-calculus/tree/mas...
If you don’t understand what it does, it’s not for you. But if you don’t understand what it does, get good.
TLDR; what happens when a very small piece of js can be run in the browser or any environment and offer a meta programming layer, that is stupid simple, but also useful because it offers Turing completeness with reflection? Also, it’s site explains what it does, but you have to center on what it is doing. “Minimal” 20 lines of rust is the entire calculus. If you don’t know what Turing complete means get out. Similarly with reflective. Modular, look at the demos.
You flunked out of putting in an effort before spouting your mouth do try and actually be useful before you respond, there are those of us actually paying attention.