> A simple way to state the proposition is: in any language there are things you cannot write in the language itself: they have to be supplied by your interpret

> A simple way to state the proposition is: in any language there are things you cannot write in the language itself: they have to be supplied by your interpreter (or the compiler generated code which is “interpreted” by the CPU). For example you can’t write OR because if the first case is true the second case is not evaluated — you can’t write that as a function. This isn't strictly correct. The problem is a function call that always evaluates its arguments on function entry. However, this is NOT a fundamental axiom. Tcl doesn't do it. John Shutt created a Scheme-like language called Kernel that doesn't do it (see: https://web.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unrestricted/jshutt.pdf https://web.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unr...). The very early Lisps all had FEXPRs which didn't do it. The issue is that you have to be able to also pass around the environment (lexical, dynamic, etc.) in which to evaluate those arguments if you don't evaluate them on entry. If you do that, you can have a consistent language that bootstraps itself with only basic support (see: Kernel). However, it doesn't necessarily optimize well--you're almost working as an interpreter continuously.