To complement leethomps answer, combinatory logic is a branch of Mathematics that was started in the 1920s by a mathematician called Moses Shönfinkel which deals with "functions that do stuff and return other functions".
This was developed by some names that may be more familiar (Haskell Curry, Alan Turing, Kurt Gödel, Bertrand Russell). It was proved to be identical to both the lambda calculus and the Turing machine and became the basis for modern computing.
What we see here are some of those key building blocks that were studied in the 20s and 30s and have been now applied to modern programming languages.
Functional languages use them a lot because you can express a lot of things as just combinations and compositions of other functions. Array languages often take this to an extreme by expressing complex numeric algorithms with only a few symbols.
What you see above is the logic/processing order of how those functions fit together. For example you can express a mean as something like `(+/#)` - a 5 letter anonymous function that can be applied to an array - because of all the applications and combinations being implicit in the structure of the language, as denoted in the link.
Many primitives in array languages match the behaviour of certain combinators in combinatory logic. The page shows (left to right) the symbol for a certain combinator, its effective operation in APL syntax where x and y are left and right arguments (APL operators are either infix or single-parameter prefix) and F and G are similarly left and right function arguments, the 'bird' is a sort of colloquial name for a particular combinator, 'TinyAPL' is the operator that matches the combinator in the author's APL implementation, and the diagram is a way of explaining how the combinator works visually
The intuition here is that combinators are higher order functions which take functions and combine them together in various ways. So for a simple example "fix" is a combinator in regular maths where
Fix f = {f(x): f(x) = x for all x in the domain of f}
So if f is a function or a group action or whatever, the fixed-point set of f is all points x in the domain of f such that f(x)=x. ie the points which are unchanged by x. So if f is a reflection, the points which sit on the axis of reflection.
The fixed-point combinator is of particular relevance to this site because it's often called the y combinator.
The first example, I, is an identity function. It takes y and returns y.
The second, K, is a constant which takes X and y and returns x.
This gets more complicated as you go along. The idea is that you get rid of a lot of the syntax for composition and have it all be implicit by what you put next to each other (given APL programs are usually one long line of a bunch of different symbols all representing functions).
Combinators are math, and a little like Lisp - building functions from primitives and operations with the ability to apply them, where even the notion of variables are functions - functions all the way down.
When considering logic and functions, when thinking in the space of combinators, you can ask questions like "What is Plus times Plus" and have a sensible result.
https://www.youtube.com/watch?v=RcVA8Nj6HEo
Combinators are awesome.
The site linked by OP is a specific collection of combinators with bird names, riffing on the "To Mock a Mockingbird" puzzle book and subsequent meme of giving combinators bird names.
Based on other existing material on the topic (like the excellent code_report youtube channel) I once wrote an introduction to combinators and lambda calculus targetted at javascript developers (mostly targetted at my younger self) [1]
Technically you cannot implement a proper Y-combinator in Lisp (well, I'm sure in Common Lisp and Racket there is some way) because the classic Y-combinator relies on lazy, not strict, evaluation. Most of the "Y-combinators" people have implemented in Lisp/Scheme/JavaScript/etc are more accurately described as the "applicative order Y-combinator" (also Z-combinator)
Funnily enough, you also cannot* implement the Y-combinator in Haskell (probably the most popular language with lazy evaluation) because the type system will not be happy with you (the Y-combinator, by it's nature, is untyped).
I wish universal and eternal patterns like this were studied more often in software engineering. Perhaps we would have a chance in hell of finding canonical representations of common structures and even programs instead of basket weaving majors fucking reinventing the wheel every 5 minutes with yet another half-baked poorly understood Python or JavaScript instantiation of a common pattern. Imagine still writing for loops and munging indices instead of expressing things in terms of higher order functions like folds or maps...
Eh, I don't need to imagine; we're still stuck at that same level of infantilism. Instead of actually graduating to higher order atoms and primitives of thought though, we can just have the AI slop out another 100k LOC. Then the system will have so much incidental complexity that it becomes impossible to distill out its essence, because there no longer is one.
While I agree that we keep reinventing stuff, in CS doesn't the ease of creating isomorphisms between different ways of doing things mean that canonicalization will always be a matter of some community choosing their favorite form, perhaps based on aesthetic or cultural reasons, rather than anything "universal and eternal"?
We can still speak of equivalence classes under said isomorphisms and choose a representative out of them, depending on the aesthetic preferences of the implementor. We are nowhere near finding equivalence classes or isomorphisms between representations because the things being compared are probably not equal, thanks to all the burrs and rough corners of incidental (non essential) complexity.
A bit of an aside: I wonder how much array-oriented languages like APL and J would benefit from being implemented on top of an interaction net machine?
I raised this in person to a number of array language implementors (and Connor Hoekstra) last year and they weren't familiar with interaction nets. I'm not sure that I was successful in convincing them that this was worth looking into, partially because I'm not yet personally convinced that this is worth looking into.
This was developed by some names that may be more familiar (Haskell Curry, Alan Turing, Kurt Gödel, Bertrand Russell). It was proved to be identical to both the lambda calculus and the Turing machine and became the basis for modern computing.
What we see here are some of those key building blocks that were studied in the 20s and 30s and have been now applied to modern programming languages.
Functional languages use them a lot because you can express a lot of things as just combinations and compositions of other functions. Array languages often take this to an extreme by expressing complex numeric algorithms with only a few symbols.
What you see above is the logic/processing order of how those functions fit together. For example you can express a mean as something like `(+/#)` - a 5 letter anonymous function that can be applied to an array - because of all the applications and combinations being implicit in the structure of the language, as denoted in the link.
BQN, another array language has a page of documentation describing the same concept for their language with a bit more explanation for the combinator newcomer: https://mlochbaum.github.io/BQN/tutorial/combinator.html
Fix f = {f(x): f(x) = x for all x in the domain of f}
So if f is a function or a group action or whatever, the fixed-point set of f is all points x in the domain of f such that f(x)=x. ie the points which are unchanged by x. So if f is a reflection, the points which sit on the axis of reflection.
The fixed-point combinator is of particular relevance to this site because it's often called the y combinator.
The first example, I, is an identity function. It takes y and returns y.
The second, K, is a constant which takes X and y and returns x.
This gets more complicated as you go along. The idea is that you get rid of a lot of the syntax for composition and have it all be implicit by what you put next to each other (given APL programs are usually one long line of a bunch of different symbols all representing functions).
The y combinator is this: λf.(λx.x x)(λx.f(x x))
Lambda diagrams get you visualizations like this:
https://tromp.github.io/cl/diagrams.html
When considering logic and functions, when thinking in the space of combinators, you can ask questions like "What is Plus times Plus" and have a sensible result. https://www.youtube.com/watch?v=RcVA8Nj6HEo
Combinators are awesome.
The site linked by OP is a specific collection of combinators with bird names, riffing on the "To Mock a Mockingbird" puzzle book and subsequent meme of giving combinators bird names.
[1]: https://static.laszlokorte.de/combinators/
Technically you cannot implement a proper Y-combinator in Lisp (well, I'm sure in Common Lisp and Racket there is some way) because the classic Y-combinator relies on lazy, not strict, evaluation. Most of the "Y-combinators" people have implemented in Lisp/Scheme/JavaScript/etc are more accurately described as the "applicative order Y-combinator" (also Z-combinator)
Funnily enough, you also cannot* implement the Y-combinator in Haskell (probably the most popular language with lazy evaluation) because the type system will not be happy with you (the Y-combinator, by it's nature, is untyped).
Eh, I don't need to imagine; we're still stuck at that same level of infantilism. Instead of actually graduating to higher order atoms and primitives of thought though, we can just have the AI slop out another 100k LOC. Then the system will have so much incidental complexity that it becomes impossible to distill out its essence, because there no longer is one.