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.

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

Of course, goto &SUB is a totally different matter.

Abigail

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.