>The world is a much kinder, nicer place than it often seems.

I realize that a lot these days. People are not inherently so bad but greed is a nasty drug that has the potential to ruin the best.

When you have nothing to offer but kindness and compassion, it is very simple to see the humanity side of things in this world and it can feel really amazing.

Yes, except without all the known disadvantages of goto. That's the whole point.

It gives you arbitrarily complex control flow even in presence of modularity. A tail call is a state transition. Without them, you'd have to resort to a big loop (which breaks modularity), or some sort of trampoline (which works but it's a bit clumsy).

For tco to be really useful you need to think in a non procedural way. Imagine that you don't have loops in your language so you need recursion to do stuff multiple times.

Also even in procedural languages there are some problems that are easier to understand and model if you use recursion, for example tree or graph like structures.

I don't know about real world "examples", but the beauty of tail-call recursion specifically is the theoretical insight that they have a one-to-one mapping with an loop-based equivalent formulation, and vice versa (which is generally not necessarily true of all recursion).

But, for languages that don't have loop constructs and you need to rely on recursion, all you need to do is write your recipe in standard loop form, and then map back to a tail-call syntax. This is often a LOT easier than trying to think of the problem in a recursive mindset from scratch. (though occasionally, the reverse is also true.)

So the only constraint for re-implementing such looped logic onto tailcalls is that this relies on the stack, which may overflow. By providing TCO you are effectively removing that restriction, so it's a very useful thing for a language to support (especially if they don't provide low-level loops).

The title "tail call optimisation" in the package above is a bit of a misnomer, since this is more of a "transformation" than an "optimisation", but effectively the whole loop-tailcall equivalence is exactly what the package mentioned above relies on to work; it uses decorators to transform tail-call recursive functions to their equivalent loop-based formulations, and thus passing the need to create multiple stacks for the recursion (and risk stack overflow), since the translated loop will now take place in a single stack frame.

Very cool. I've been sketching out a relay computer myself. Mostly unbuilt but I have tested a variety of circuits implementing gates, latches, oscillators, flip flops, counters, registers all using only SPST reed relays.

I'm fixated on speed. I connected some reed relays in a 3 stage ring oscillator and it ran at 1.8 kHz. That has me thinking that with a pipeline 100 instructions a second might be attainable. Reed relay logic seems to be fast enough for a UART at 50 baud. Teletype interactivity is a stretch goal.

My program counter is also 12 bits! And I've also been using Digital to simulate parts of it. Great tool for that.

The current design is RISC-like with a 12 bit word requiring 4 cycles for most instructions. I have an old version of the design specified in gate level Verilog. I should publish that. Though I'm forever tinkering with the control such that it'll probably never be done. Karnaugh maps are like Sudoku.