I wouldn't say gotos are stupid, dangerous maybe but not stupid. I think it's a more natural way to move around as it's closer to english. However, it can get you into quite a bit of trouble so it is recommended that you not use them. So much so that many people are afraid of using a goto and refuse to use them under any circumstance. I've never really had a need to use them as most of the time a nice loop with some if/then/else statements will do and makes debugging easier but I wouldn't not use a goto just because they are bad. I would just triple check that portion of the code.
So why is it bizzare and stupid? You never really gave an explanation other than it can jump anywhere.... well yeah, that's kindof the point. Kindof like if we need to start over and reinit stuff goto the beginning. If we are in the middle of a program that is not designed to do something like this would you rather 1) rewrite your code and put a bunch of checks to see if we need to start or 2) put in a goto BEGINING:? Of course where you run into trouble is if something is open and you don't properly close it etc... but if you clean up before jumping it's not a problem.
| [reply] |
I thought he meant it was stupid as in not smart, as in it jumps anywhere regardless and doesn't do anything thinking about it.
| [reply] |
It's bizzare, particularly in the goto EXPR form, because there is no way to calculate the jump until runtime. Depending on the complexity of EXPR, code maintnance could be hopeless. Also, this causes a linear scan of your code, so your jump will be slower (in the worst case) if your code base is larger. Lord forbid if Hitler had ever discovered the sinister power behind goto EXPR (I claim exemption from Godwin's law).
Of course, goto &SUB is a totally different matter.
----
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l]
[select] |
Also, this causes a linear scan of your code, so your jump will be slower (in the worst case) if your code base is larger.
That's just a bit misleading. If I didn't know how it really works, I'd take it to mean that it starts at the beginning of your program and scans the whole thing for the label. What it actually does is multiple linear scans from the innermost dynamic scope to the outermost dynamic scope. Since most gotos are local, the operation is usually relatively fast regardless of the code base size.
But you did say "in the worst case", so I can't quibble about that. It's just the implication that there is only one linear scan of all the code.
And in fact, none of the individual scans are quite "linear" either. More like "cyclical". In a given dynamic scope, it always starts scanning forward first, and when it hits the end of the scope, it starts back at the beginning until it
comes back to the place it started. Not only does this optimize for the fact that most gotos go forward rather than backward, but it also naturally cuts out of the loop any inner scope we already searched without an extra test.
That doesn't stop it from being bizarre though. And it will bite you hard if you misspell the label. Plus I don't know if Perl 6 will support goto EXPR, because it's a lot of hard work, and you have to be a crazy megalomaniac to do it. (I'd give examples of megalomaniacs, but I'm not exempt from Godwin's Law. Where do you apply for that?)
| [reply]
[d/l]
[select] |
Of course, goto &SUB is a totally different matter.
You do realize that goto &SUB can't calculate
where to jump to until runtime either, do you? And that
the fact that the linear scan for a label for goto EXPR is a perl implementation issue, for which the
only reason it's not fixed is that noone can be bothered
about it?
Abigail
| [reply] |
