Re: Re: Duff's Device

[MCS]

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.

[eric256]

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.

[hardburn]

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.

[TimToady]

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?)

[Abigail-II]

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

[TimToady]

You do realize that goto &SUB can't calculate where to jump to until runtime either, do you?

That's also a little bit misleading. No scan is done for &SUB at run time. The symbol is resolved at compile time, just like an ordinary variable. And just like an ordinary variable, there are several levels of indirection in there before you get to the "actual" value, in this case a jump address. But nearly all the work done by goto &SUB is in stripping the old context off the stacks and substituting a new context. Finding the address is negligible next to this, unless you happen to trigger an autoload.

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?

Well, it's a little more intentional than that. That's one of the ways in which we actively discourage people from using goto. And really, goto was only put in there in the first place to make the sed-to-Perl translator a little easier to write. (Well, and because it was an interesting challenge...)

But yes, it would be possible to at least cache the jump labels that have been found already, even if you don't precompute anything at compile time. Though you still have to do the work of scope winding or unwinding even if you know the actual address. That will only get more interesting in Perl 6, where all blocks are logically considered closures, and some of them might actually have to be implemented that way. Though that's close to the definition of the blocks you can't go into because they have some initialization that you can't bypass, so we might just disallow going into any kind of closure that can't be optimized away.