Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.lang.pascal,net.lang
Subject: Re: a goto without a label?
Message-ID: <2619@umcp-cs.UUCP>
Date: Fri, 25-Jul-86 20:54:05 EDT
Article-I.D.: umcp-cs.2619
Posted: Fri Jul 25 20:54:05 1986
Date-Received: Fri, 25-Jul-86 22:12:51 EDT
References: <2943@ism780c.UUCP> <550@cbmvax.cbmvax.cbm.UUCP> <2954@ism780c.UUCP>
Reply-To: chris@maryland.UUCP (Chris Torek)
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 32
Xref: mnetor net.lang.pascal:347 net.lang:1136

In article <2954@ism780c.UUCP> marty@ism780c.UUCP (Marty Smith) writes:
>ps.  Note that a C break statement is nothing more than a goto without
>specifying the label.  Surely you must agree that a goto without a label
>makes for more difficult understanding than a goto with a label.

Why must I agree?  I do not.

A `goto' without a label must have a defined behaviour.  If this
behaviour is simple enough, the construct will be easy to understand.
For example, the FORTRAN `STOP' statement is equivalent to a Pascal
`goto 9999' if label 9999 is just before the program end.  In other
words, STOP is a `go to program end' statement, or a goto without a
label.  It is also trivial to understand.

A C `break' is a `go out of the innermost enclosing loop or switch',
and as such requires knowing its context.  The more locality of
reference in a statement, the easier that statement is to understand
by itself, and `break' violates this locality.  But so does `end
while', and in much the same way; yet I have never heard it argued
that an `end while' `statement' is hard to understand.  (`End while'
is semantically a control flow bracket but is written as a statement.
The same is true of `break'.)

In a language with `break' and `continue' statements, the body of
a loop is not always entirely executed each time the loop test
succeeds.  If one makes the assumption that it is, and that turns
out to be false, naturally one will have trouble understanding the
code.  It seems simpler not to make that assumption.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu