Breaking out - the ratfor approach

[Geoff Kuenning]

In article <2122 at usceast.UUCP> ted at usceast.UUCP (Ted Nolan) writes:

>If anyone really feels strongly enough about a special syntax for breaking out
>of multiple loops, why not write a preprocessor to do it for you, as ratfor
>imposes structure on FORTRAN?  Then you and your organization have your coveted
>code cleanliness and can still export portable code after the preprocessing
>(or you could export the preprocessor with the code). One of the nice things
>about gotos is that you can map any control structure into them.  I don't
>think this is something that should be part of the "real" language.

And one of the worst things about goto's, as I pointed out once before in
this discussion but seems to have been forgotten, is that you *CAN'T*
do certain kind of very valuable optimizations when goto's are present.  In
practice, this means that most compiler writers choose not to do these
optimizations if the language, or at least the routine being compiled,
contains and goto's at all.  A pretty high price to pay for a feature even
the let's-keep-C-C types recognize as being of limited usefulness.
(Indeed, I can recall only one article that came out in support of goto's
for any purpose except breaking out of loops).

Go back and read Dijkstra's 1967 letter;  it's not long.  It has two
objections to goto's, and gives equal weight to both.  One is the
readability/maintainability issue, which is the only one that has been
discussed in the current controversy.  The other is the fact that goto's
severely hurt our ability to write optimizing compilers, and thus our ability
to break away from the expense and drudgery of writing assembly language.

So tell me, folks:  do *you* have a global data flow analysis algorithm that
works in the presence of unrestricted goto's?
-- 

	Geoff Kuenning
	First Systems Corporation
	...!ihnp4!trwrb!desint!geoff