Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!caip!ucla-cs!sdcrdcf!ism780c!marty
From: marty@ism780c.UUCP (Marty Smith)
Newsgroups: net.lang.pascal,net.lang
Subject: Re: a goto without a label?
Message-ID: <2985@ism780c.UUCP>
Date: Mon, 28-Jul-86 12:57:01 EDT
Article-I.D.: ism780c.2985
Posted: Mon Jul 28 12:57:01 1986
Date-Received: Thu, 31-Jul-86 01:59:58 EDT
References: <2943@ism780c.UUCP> <550@cbmvax.cbmvax.cbm.UUCP> <2954@ism780c.UUCP> <2619@umcp-cs.UUCP>
Reply-To: marty@ism780c.UUCP (Marty Smith)
Organization: Interactive Systems Corp., Santa Monica, CA
Lines: 46
Xref: mnetor net.lang.pascal:352 net.lang:1140

In article <2619@umcp-cs.UUCP> chris@maryland.UUCP (Chris Torek) writes:
>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.
>
Agreed.  But what I meant by "more difficult to understand" had more to do
with the destination of the goto or break than with the source.  When I
see a labeled statement, I presume there is more than one way to get to the
statement and hence more than one set of initial conditions for the
statement.  If I use break instead of goto, there is no label to tip me off.

				Martin Smith






>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