One reason goto isn't implement is because it's difficult: You'd have to keep track of the stack depth at both the source and the destination to do it correctly. The current byte code generator (see docode.c) is a simple recursive thing that only keeps track of that around the source, so it'd either have to be changed into some multipass thingie or use backpatching of the generated code.
Supporting jumps into special blocks like gauge and catch would also be tricky. Especially catch since you'd first have to jump to the start of it to set up the longjmp correctly, and then have a test there to jump on to the destination.
A goto would also make it necessary to introduce some arbitrary rule to handle the well known jumping-past-initializations case.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-13 20:51: Subject: goto
On Tue, May 13, 2003 at 08:35:02PM +0200, Martin Nilsson (lambda) @ Pike (-) developers forum wrote:
Of course it lessens readability when you try to emulate goto in a language that has no goto concept. The "correct" solution is to design the code differently.
The "correct" code is the code that works as expected and easy to understand.
This way, if use of "goto" improves readability and undestanding - it should be done instead of designing code to avoid something. Why to create obstacles and then avoid then, instead of going directly to the goal? :)
NB: I would like to know, if possible, the reason why "goto" is not included in Pike (except well-known "the "goto" is evil" - this is not the reason, this is like "the appless are evil because I don't like them").
Regards, /Al
/ Brevbäraren