The disadvantage of introducing $ is twofold:
- It is a new ‘keyword’ to learn; you will not be able to see what happens simply by reading the code. You have to have learned about what it does beforehand.
- Actually,
$itself it is not a keyword but an operator (a symbol), which means that it is even more difficult to find out what it means:
- It does not convey a meaning itself. (which a keyword like
this_functionwould do) - It is difficult to search for, because
$is overloaded to mean many different things in different contexts, and because many search-tools do not work with non-alphanumeric input.
So:
Introducing $ is bad because it is unreadable.
Introducing this_function or similar still is bad, because it still is a name that appears out of thin air, as well as having to be introduced as a new language feature. (Adding a language feature is remarkable easy, but changing or removing a feature is extremely difficult).
So either we try very hard to get it ‘right’, or we decide that this is not worth it and keep this functionality to be implemented in library-land.
As to get some intuition for the Y-combinator: In a language where we can refer to things by name, it could be defined as
y1 = fn fun -> fn a -> fun.(fun, a) end end
y2 = fn fun -> fn a, b -> fun.(fun, a, b) end end
y3 = fn fun -> fn a, b, c -> fun.(fun, a, b, c) end end
(Obviously, a different variant would be needed for each arity. In the example you see definitions it for arity-1 up to arity-3. This is the main reason why we could use a macro, because it would take care of the non-matching arities for us).
