3 ms·

> COBOL has no stack... So no function calls?

by pkaye 9y ago

nafey 9y ago
Although I am not familiar with COBOL I am assuming this means you have to indicate where the control returns to after a function ends
- jrq 9y ago
  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.
  - joshuaduffy 9y ago
    Correct. They are called subroutines in COBOL.
  - blattimwind 9y ago
    Recursive and iterative functions have the same computational power.
    - adrianN 9y ago
      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.
  - Koshkin 9y ago
    > how much power Do not forget that when COBOL was created mainframes were less powerful than today's microcontrollers.
  - kbp 9y ago
    > 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/handheld/Connected/BOOKS/IGY3PG20/4.1.4 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.
    - jrq 9y ago
      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!
kbp 9y ago
> So no function calls? No recursive ones. If you forbid (direct or indirect) recursion, then a function's local variables can all be static rather than stack-allocated. Similarly, each function could have a hidden, static "return address" variable (since all parameters are static, it's really just a hidden parameter) that is set behind the scenes when a procedure is invoked and jumped to when it exits. edit: I was just guessing how you'd do return addresses, but it looks like that is how they used to work. From Wikipedia: "Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily deep levels of subroutine nesting, but does not support recursive subroutines." Ancient Fortran also didn't support recursive procedures, and they were only sneaked into Algol 60: https://vanemden.wordpress.com/2014/06/18/how-recursion-got-into-programming-a-comedy-of-errors-3/ https://vanemden.wordpress.com/2014/06/18/how-recursion-got-...

> COBOL has no stack... So no function calls?

by pkaye 9y ago

> COBOL has no stack... So no function calls?

Although I am not familiar with COBOL I am assuming this means you have to indicate where the control returns to after a function ends

jrq 9y ago
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.
- joshuaduffy 9y ago
  Correct. They are called subroutines in COBOL.
- blattimwind 9y ago
  Recursive and iterative functions have the same computational power.
  - adrianN 9y ago
    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.
- Koshkin 9y ago
  > how much power Do not forget that when COBOL was created mainframes were less powerful than today's microcontrollers.
- kbp 9y ago
  > 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/handheld/Connected/BOOKS/IGY3PG20/4.1.4 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.
  - jrq 9y ago
    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!

kbp 9y ago

> So no function calls? No recursive ones. If you forbid (direct or indirect) recursion, then a function's local variables can all be static rather than stack-allocated. Similarly, each function could have a hidden, static "return address" variable (since all parameters are static, it's really just a hidden parameter) that is set behind the scenes when a procedure is invoked and jumped to when it exits. edit: I was just guessing how you'd do return addresses, but it looks like that is how they used to work. From Wikipedia: "Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily deep levels of subroutine nesting, but does not support recursive subroutines." Ancient Fortran also didn't support recursive procedures, and they were only sneaked into Algol 60: https://vanemden.wordpress.com/2014/06/18/how-recursion-got-into-programming-a-comedy-of-errors-3/ https://vanemden.wordpress.com/2014/06/18/how-recursion-got-...