Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cca.UUCP
Path: utzoo!linus!decvax!cca!g-rh
From: g-rh@cca.UUCP (Richard Harter)
Newsgroups: net.lang
Subject: Re: and if you put this in your languag
Message-ID: <6925@cca.UUCP>
Date: Sun, 30-Mar-86 01:32:04 EST
Article-I.D.: cca.6925
Posted: Sun Mar 30 01:32:04 1986
Date-Received: Wed, 2-Apr-86 06:07:58 EST
References: <1187@mmintl.UUCP> <>
Reply-To: g-rh@cca.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge
Lines: 75
Summary: Care and feeding of goto's

In article <> aglew@ccvaxa.UUCP writes:
>
>Talking about the IFs that want to merge different paths back together,
>g-rh@cca.UUCP writes:
>
>>	I went on to outline a schematic suggestion for using flags and
>>Jem wasn't happy with that.  Frankly, I'm not enthusiastic about flags
>>either.  The real difficulty is that there is not good solution to the
>>problem which can be roughly stated as follows: Given a net of if-then-else
>>logic in which a functional block of code occurs more than once, how do
>>you structure the code?  Some possible solutions are:
>>
>>(a)	Duplicate the block
>>(b)	Replace the block by a procedure
>>(c)	Replace the block by a macro
>>(d)	Separate the logic structure and the executable structure,
>>	using flags to control the execution
>>(e)	Programming tricks based on language syntax
>
>To these we can also add 
> (f) using GOTOs
>if the paths of execution converge.
>
>GOTOs are not EVIL; they are a tool that can be used in structured programming
>just as any other tool. They are a tool that is frequently misused, 
>sufficiently so that you should always think three times before using a GOTO,
>(just like you should always think twice before using a gun, but sometimes
>you may have to) but sometimes they are the best thing to do.
>
>structured programming != GOTOless programming.

	Au contraire, "structured programming" == GOTOless programming.
Well structured programming, on the other hand ... :-).  Personally, I
have no objection to GOTOs -- I average about one GOTO per 10,000 lines
of code in languages like C and PL/I.  In general, I find that GOTOs
come up as a generalized escape statement, i.e. you have a block of
code that has multiple routes out of the block.  The usual solution is
to set up the code as a procedure and use the return statement as a
generalized escape statement; however this doesn't work if there is
a cleanup sequence to execute before leaving the routine.  I would like
to have the following structures available:

	BLOCK label_name {
	  .....
	  }

	LOOP label_name {
	  .....
	  }

	FRAGMENT label_name {
	  .....
	  }

A FRAGMENT is essentially an internal procedure without arguments;
a BLOCK is a labelled block of code; and a LOOP is a labelled (forever)
loop.  The command statement that I want is:

	escape [(block/loop)_label_name] [via fragment_name]

This statement transfers control to the next statement after the
block (loop) but first executes the named fragment.  If there is
no block/loop label name the escape leaves the current block/loop.
If there is no via clause control is transferred directly to the
next statement.  Every once in a while I find that I would really
like to have something like this available.

	To return to the issue originally under discussion, I agree
that GOTOs ought to be listed among the alternatives but I don't
think that they are appropriate in the kind of situation originally
presented.  GOTOs are useful as an ultimate escape statement.  In my
opinion they are not advisable if you merely mean to conditionally
skip blocks of code.

	Richard Harter, SMDS Inc.