> ... is there more to the significance of tail call optimization that I am unaware of? Looking at TCO in isolation is missing the big picture. You need to con

> ... is there more to the significance of tail call optimization that I am unaware of? Looking at TCO in isolation is missing the big picture. You need to consider other language features that uses TCO. In Scheme/Racket the specification says that implementations must support an "unbounded number of active tail calls" (for implementations that use stack frames to implement function calls, this means that TCO must be supported). This requirement is a global requirement. The other feature of Scheme/Racket that compelled the authors of the Scheme standard to require an "unbounded number of active tail calls" are macros. Macros in Scheme allow users of the language to add new bindings constructs (e.g. pattern matching), new control constructs etc to the language using syntax rewrite rules. In Scheme these rewrite rules work locally. [Racket allows for global program rewrites too]. There is a range of constructs that are possible to specify locally - if tail calls don't allocate that is. As an example: There are embeddings of Prolog in Scheme. If Scheme didn't support TCO then a global transformation of the program is needed. So instead of writing local macros - a full compiler is needed. These days it is common to see JavaScript as a compilation target. Babel compiles JavaScript+NewFeatures to GoodOldJavaScript. The features that allow local rewriting are much easier to implement than the ones that require a global transformation. If JavaScript had TCO it would be much easier to use JavaScript as a compilation target.