Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!comp.vuw.ac.nz!canterbury!phys169
From: phys169@csc.canterbury.ac.nz
Newsgroups: comp.lang.pascal
Subject: Re: Gotos are ok
Message-ID: <1991Jan28.112029.50@csc.canterbury.ac.nz>
Date: 27 Jan 91 22:29:16 GMT
References: <11724@j.cc.purdue.edu>
Lines: 55

In article <11724@j.cc.purdue.edu>, zhou@brazil.psych.purdue.edu (Albert Zhou) writes:
> When I posted the original
> article, I was plagued by the limitation of "exit" implemented on Turbo
> Pascal. I wanted exit several nested subroutines altogether, but I
> could find a direct way to do it.

That would be extremely useful, but is hard to implement, especially without a
frame pointer register. As I recall, Burroughs Algol did this "bad goto" quite 
slowly, since the stack could contain all sorts of rubbish. Somebody mentioned a
version of Pascal (UCSD) that could do this. Maybe Borland may adopt it some
day. I feel that the main use of this facility would be in error handling,
where a plain exit from the procedures might not be enough, however. FORTRAN
has a method of passing an alternative exit label to a routine (dirty but
powerful). Better still, might be an "on error=expr ..." construct before the
calls, and a "generate error(n)" within the procedures. The main question is
how you think about side-effects. 

Exiting loops within loops is easier in theory, but could cause confusion. Your
example...
> 		for i := 1 to 2
> 		  for j := 1 to 3 do
> 		  begin
>           	     ...
> 		     if c then exit(2)
> 		  end
> 
suffers from the same risks (as far as simple mistakes on the programmer's part
going undetected by the compiler is concerned) as the humble goto. Agreed, it
is darned useful, as is exitting from several layers of procedure, but some
discussion is needed as to the best way to implement it. I prefer an exit to a
goto, but they have similar problems (what you write in your program, and what
you think you're coding, can be different, and it tends to break the main line
of the code, which can upset programmers' concentration).

My favourite is to require the NAME of the procedure or loop to be given with
the exit (e.g. "if c then exit for i" in the above example, so you could
add complexity (a 3rd loop, another if, etc, and the program would work the
same way). I would also like to see a "next" statement for loops, which in
effect goes to a label before the end of the (given) loop, e.g. "next j". It is
possible to manage without the "next" by using (convoluted, in my opinion) if's
or procedure calls, or (of course) a goto.

The best way to debate emotive issues (like the goto question) is, as you have
done, provide an example of what is required, and it is then up to the various
"camps" to supply neat answers to it. The particular problem, exitting from
several layers of routine, can be done in Turbo Pascal with an if statement
following each call to procedures that may be affected (which could be a big or
a little problem, and tends to be sensitive to small changes in the program),
or a (dirty) method involving saving the stack pointer before the nested
procedure calls and letting some error-handling routine (perhaps a software
interrupt, since we're talking about TP) use brute force to exit. (not that I'm
recommending the latter, but that might be behind a future compiler's
implementation, mightn't it?). Comments?

Mark Aitchison, Physics, University of Canterbury, New Zealand.