Goto Command

[ezzetabi]

I am learning Autoit3 and reading the F.A.Q. I saw this interesting answer

4. Where is the "goto" command?

Gone. It's evil. No, you can't ask why - it just is. It's like that lump of rock they find in the microwave at the end of the film Time Bandits

Ok. It is true, but I feel necessary explain why for the ones that are too young in the computer world to know the notivation.

The Goto command is very powerful, it allows leave a loop and enter an other with no need of other code, it allows to make subrutines and move part of code without problem... BUT... there is a great but...

in the computer history GoTo as been largely used in the first years of programming.

Programmers, after some time, saw that it were extremly hard understand the code that they made. Often were better remake the program from scratch instead of modify it.

The main fault was the use of the GoTo that make the code unreadable...

So Goto has been deprecated and, even if often keept for legacy reason, unused.

Ok... Feel free to correct my english mistakes

[Valik]

I think the main reason Goto is evil is not because it creates difficult to read code, but because its so extremely easy to jump from point a to point b to point c that its too easy to forget to initialize or declare a variable or something. With all that jumping around, its hard to figure out just where in the hell the actual bug is coming from.

[ben_josephs]

If you restrict yourself to sequence (;), alternation (if) and iteration (do) you can construct sequential programs that you can reason about; it's possible to prove things about these programs. For example, it's possible to make statements about the values of the variables at all points in the program.

With jumps, you don't know where you came from. So you don't know what's true when you get there.

The complete rigorous treatment of serial programs (ones without concurrency) that contain no jumps involves simple mathematical constructs describing (roughly*) the state of all the variables (a mapping from locations to values) and the way each component of the program transforms the state (a mapping from states to states). Lots of mappings, mappings of mappings, and mappings of mappings of mappings...

(* It's this description of the maths that's rough, not the mathematical description of the program. )

To provide a rigorous treatment of serial programs with unconstrained jumps you have to throw all that away. Programs are no longer simple state transformations, but continuation transformations. These are not simple at all. A continuation is a mathematical description of "the rest of the execution of the program", and each component of the program is described as a transformation that, given a continuation (what's left to execute after the component has run) provides a new continuation (what's left to execute before the component has run). This is, of course, all backwards. Such is the consequence of using jumps.

In this way the destinations of jumps (labels) are made real - they are continuations - and can be passed about the program and used in goto commands.

Continuations are a lovely thing; that is, they beautifully capture the essence of an existing construct. But, in doing so, the show just how horrible that construct is. The mathematics doesn't help you prove anything about your program; it shows you just what a hopeless task that is.

Of course, we don't all spend our programming lives proving things about programs. (Mind you, some people do.) But what the maths shows is that, in the presence of jumps, we couldn't do that even if we wanted and tried to. This is a devastating fact. It means that when we believe we understand a program with a jump in it, then unless in some sense we have mentally rewritten it without the jump, we are probably mistaken. And if we have an intelligible rewritten program, why do we not use that one? (Note the use of the expression "unconstrained jump" above. Some jumps are more equal than others. Some can be rewritten more readily than others.)

Once you have looked a continuation in the eye you will never write another goto.

[GrahamS]

I assume that we have all read Go To Statement Considered Harmful by Edsger W. Dijkstra

[ben_josephs]

I assume that we have all read Go To Statement Considered Harmful by Edsger W. Dijkstra

That article has always seemed more obscure to me than the point it makes. What Dijkstra pointed out in 1968 is that with jumps in your program you can't readily describe the progress of its execution. With just sequence and alternation, you can identify each point in the execution of the program with a point in the program text. With function calls added, you can identify each point of execution with a sequence of points in the program text (the instruction counter stack). With iteration, you need iteration indices (loop counters) as well. With jumps, you are on your own. You have to choose some arbitrary measure that both is capable of identifying any point of execution and is useful for reasoning about that execution. If you can find one.

It's a sad fact that 36 years on the case still needs to be made.

[GrahamS]

I agree that the article is a bit obscure and of course it misses out some of the more practical reasons why gotos are not just harmful but are actually

My favourite is what should the following display?

global $a = 0
A()
MsgBox(0, "The answer is", $a)

Func A()
  $a = $a + 1
  B()
  $a = $a + 1
  Label1:
  $a = $a + 1
  exit
EndFunc

Func B()
  $a = $a + 1
  goto Label1
  $a = $a + 1
EndFunc

It's a sad fact that 36 years on the case still needs to be made.

Too true

[Valik]

Is the correct answer "nothing" because of the exit? (See! This is why goto's are bad! I'm relegated to asking the author if that's the intention because they are crappy, so I think GrahamS is proving his point well).

[GrahamS]

Is the correct answer "nothing" because of the exit?  (See!  This is why goto's are bad!  I'm relegated to asking the author if that's the intention because they are crappy, so I think GrahamS is proving his point well).

No GrahamS is just proving how dumb he really is :iamstupid: :iamstupid: :iamstupid:

The real example:

global $a = 0
A()
MsgBox(0, "The answer is", $a)

Func A()
 $a = $a + 1
 B()
 $a = $a + 1
 Label1:
 $a = $a + 1
EndFunc

Func B()
 $a = $a + 1
 goto Label1
 $a = $a + 1
EndFunc

How did that exit sneak in there???

[CyberSlug]

Assuming no variable-scoping trickery, I guess 3 is the answer.

[Jon]

When I was pondering adding goto to help v2 to v3 conversion I thought of that example. I was going to make it fail because you shouldn't be able to goto a different function.

[ben_josephs]

When I was pondering adding goto to help v2 to v3 conversion I thought of that example.  I was going to make it fail because you shouldn't be able to goto a different function.

Agreed. I can't see a way to give that program meaning, let alone a value.

Jumping out of a function is OK (in a rather weak sense of "OK"). But jumping into one is not. What state is its local stack frame in? Where does it return to? These questions can only have arbitrary answers that cannot be derived from considerations of program structure ('cos it hasn't got a structure .)

[GrahamS]

Assuming no variable-scoping trickery, I guess 3 is the answer.

You could make an equally valid argument for 5! The assumption is that we're using a program stack to contain the return address (and, although not present in this example, any local variables) - this is the "natural" way to implement function calls since processing chips normally contain support for this in their assembly labguage. The problem is that when you jump out of function B you haven't popped the return address yet. So when you return from function A you use the return address on the stack which returns you back into function A! You then increment $a twice more before returning to the main program.

There are ways round this. You could pop the stack when you jump out of a function - but what would happen if you jumped into a third function C? Where wuold you return to then. Or you could, as Jon suggested, ban gotos from leaving the scope of a function. But what about loops? They have similar problems.

The point is that from inspecting the program you have no idea what the answer should be. It is implementation dependent and requires knowledge of computer operation to work out what it does.

This ways lies madness (not least for the poor sod who has to implement this).

Better by far to remove gotos completely

[ben_josephs]

The assumption is that we're using a program stack to contain the return address (and, although not present in this example, any local variables) - this is the "natural" way to implement function calls since processing chips normally contain support for this in their assembly labguage.

Other way round. Instruction sets are like this precisely to support this concept of procedure calls.

What kind of labguage do you use in your assembly laboratory?

The point is that from inspecting the program you have no idea what the answer should be... This ways lies madness... Better by far to remove gotos completely

Indeed!

[GrahamS]

What kind of labguage do you use in your assembly laboratory?

Gobbledy-gook on a dyslexia chip

Obviously I've been reading the Gruniad too much (I wonder how many people will understand that reference )

[ben_josephs]

Obviously I've been reading the Gruniad too much (I wonder how many people will understand that reference )

Our Brummy friend should, at least.

[GrahamS]

Actually just read the FAQ where is says

If there is a massive outcry about this after the launch of v3 then I may add it back in, but only to help people convert scripts.

Jon - Please, Please, Please don't! I'd rather help people convert their 5,000 line V2 script myself than see the goto resurrected

goto

[ben_josephs]

Gruniad

A very Grauniadism!

[Jon]

I've had a huge 1 complaint so far. But thinking about it, it is actually very very diffilcult to add. I can't even work out how you would unwind all the while/for/select stacks if a goto appeared. So it will probably never happen due to being evil AND being really hard to implement.