Before the peanut gallery starts to come down on this guy, you have to understand why goto was so problematic to begin with. The kneejerk response is "Spaghetti code!", and I applaud you at being able to parrot, however the actual reason has more meat to it.
Way back before the invention of context based returning, you would have to write a bunch of additional code at the end of a block of code in able to go back where you came from. So if you wanted to reuse a code block, you would have to set a global variable (because originally you couldn't pass one) and once you got there, you would have to use that variable to get back, so the best reusable code would invariably end up looking like spaghetti to the untrained eye. These days with functions, classes, inheritance, switches, exceptions returns and whatnot this is no longer an issue; You can write code without generating spaghetti, in fact most languages use it in such limited way that it is impossible. Its use is no more dangerous than using a return in the wrong place.
Surely all you need is a call stack to implement functions that can be called more than once at a single time?
invariably end up looking like spaghetti to the untrained eye
IIRC the function call procedure in the machine language used by Donald Knuth in his Art of Computer Programming books (MIX) modified the jump instruction at the end of the function to jump back to the function call site.
I guess early compilers for FORTRAN that didn't allow recursion must have done something similar.
My earliest machine only had 12k to work with, and a lot of that was wasted by the programming language if it was interpreted, so I have to say that this was not always the case to make a call stack with low memory machines. Also consider that many programs weren't even threaded and people were still using machines that couldn't multiprocess for years
In case that wasn't a rhetorical question, constructs using goto can be equivalent to a tail-recursive function call, and can also be used to simulate a return from a function, and even a return from multiple functions, as with setjmp or exception handling. Usually you wouldn't need this, but it can be useful in a language without coroutines, where you maintain what would be a separate call stack as an explicit data structure. It's also useful in languages without continuations for implementing backtracking algorithms, where you want your program to, in a sense, go back in time. If you're interested in exploring this subject, read Donald Knuth's paper "Structured Programming with Goto Statements", and look into.the Lambda Papers by Steele and Sussman, for example "Lambda the Ultimate GOTO".
10 comments
5 u/0x7a69 21 Sep 2015 14:11
Before the peanut gallery starts to come down on this guy, you have to understand why goto was so problematic to begin with. The kneejerk response is "Spaghetti code!", and I applaud you at being able to parrot, however the actual reason has more meat to it.
Way back before the invention of context based returning, you would have to write a bunch of additional code at the end of a block of code in able to go back where you came from. So if you wanted to reuse a code block, you would have to set a global variable (because originally you couldn't pass one) and once you got there, you would have to use that variable to get back, so the best reusable code would invariably end up looking like spaghetti to the untrained eye. These days with functions, classes, inheritance, switches, exceptions returns and whatnot this is no longer an issue; You can write code without generating spaghetti, in fact most languages use it in such limited way that it is impossible. Its use is no more dangerous than using a return in the wrong place.
*edit - "meat more", I just woke up.
0 u/svipbo [OP] 21 Sep 2015 15:28
Surely all you need is a call stack to implement functions that can be called more than once at a single time?
IIRC the function call procedure in the machine language used by Donald Knuth in his Art of Computer Programming books (MIX) modified the jump instruction at the end of the function to jump back to the function call site.
I guess early compilers for FORTRAN that didn't allow recursion must have done something similar.
0 u/0x7a69 21 Sep 2015 16:50
My earliest machine only had 12k to work with, and a lot of that was wasted by the programming language if it was interpreted, so I have to say that this was not always the case to make a call stack with low memory machines. Also consider that many programs weren't even threaded and people were still using machines that couldn't multiprocess for years
0 u/TAz00 21 Sep 2015 18:24
hehe, has meat more
3 u/PolishPandaBear 21 Sep 2015 11:49
Yay! Finally an easy way to write spaghetti code in Python!
2 u/TAz00 21 Sep 2015 12:21
Asuming the hard way is to use deprecated and obscure libraries instead?
1 u/Master_Admin 21 Sep 2015 17:22
Why would you want to use goto anyway?
1 u/svipbo [OP] 22 Sep 2015 20:13
In case that wasn't a rhetorical question, constructs using goto can be equivalent to a tail-recursive function call, and can also be used to simulate a return from a function, and even a return from multiple functions, as with
setjmpor exception handling. Usually you wouldn't need this, but it can be useful in a language without coroutines, where you maintain what would be a separate call stack as an explicit data structure. It's also useful in languages without continuations for implementing backtracking algorithms, where you want your program to, in a sense, go back in time. If you're interested in exploring this subject, read Donald Knuth's paper "Structured Programming with Goto Statements", and look into.the Lambda Papers by Steele and Sussman, for example "Lambda the Ultimate GOTO".1 u/multidan 21 Sep 2015 21:09
That icon though.