So that's kind of like a coroutine. Taking recursion away seems like an unnecessary limitation, considering how much power main frames have. Resource efficiency is great and all, and certainly there's a benefit to not hammering the stack as often, but that takes away an entire category of definitions you can't express, right?

Maybe someone who writes cobol could chime in on this.

> Taking recursion away seems like an unnecessary limitation

Modern Cobol doesn't seem to have this limitation, eg http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handhel.... When Cobol originally appeared, call stacks weren't standard, Lisp didn't exist yet, and neither Fortran nor Algol supported recursive functions; it made sense at the time.

Ohhhhhh, of course!

Gosh, thanks. I sometimes hold historical technology to unfair standards because I'm not thinking about the continuity of it all.

Crazy to think twenty-somethings are out there hacking COBOL!

> how much power

Do not forget that when COBOL was created mainframes were less powerful than today's microcontrollers.

Recursive and iterative functions have the same computational power.

And every computable function can be expressed in Brainfuck. That doesn't mean that some algorithms are a lot more elegantly expressed when your language supports recursion.

Correct. They are called subroutines in COBOL.