Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site rochester.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!rochester!quiroz
From: quiroz@rochester.UUCP (Cesar Quiroz)
Newsgroups: net.lang.c
Subject: Nested loops? gotos? ANSI standard?
Message-ID: <2157@rochester.UUCP>
Date: Sat, 13-Oct-84 21:42:51 EDT
Article-I.D.: rocheste.2157
Posted: Sat Oct 13 21:42:51 1984
Date-Received: Mon, 15-Oct-84 01:39:17 EDT
References: <129@ssc-vax.UUCP>, <1801@pegasus.UUCP> <4886@duke.UUCP>, <2085@rochester.UUCP> <4901@duke.UUCP>
Organization: U. of Rochester, CS Dept.
Lines: 114

(If I may insist ...)

Just in case it wasn't clear in my previous submission: what attracted
my attention was the connection of this issue with a possible C standard.
Under that impression, I understand that if we want to improve the language 
a little bit ('optimize', in C parlance), new features to be considered should
not break too many programs (not mine, at least ...).  I defended the opinion
that the proposed <label>: <compound statement> construction would fit nicely
(provided obvious semantics and consistency constraints).  It is assuredly
not the best thing to do (to add features isn't a substitute to more radical
redesign), but is the best compromise when all the others are considered.

Now, if we forget for a while about the C standard, we can consider this
problem under a different perspective: What to do if you are REALLY
interested in speed (or some other real-world constraint) and have to
use the language as it is today.  In that case, the main point made by
Charlie Martin (...mcnc!duke!crm) makes sense. To witness:
> 
> Let me make another attempt to make my argument clear -- I claim that
> while it is indeed true that ANY algorithm can be expressed in
> proper structured-programming-without-goto's (proven by Boehm &
> Jacopini), there are things which one often wants to do which are
> best expressed in current programming languages (modulo efficiency
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> constraints) by doing them with a goto.  The example that we have
> been discussing is one of those.
> 
And that is clearly the case.

The problem is: It still seems to me that we were discussing a potential
C standard. Either we concentrate on it, or in current best usage, or
we state a new subject line. (I tried to edit the subject line of this
article, I hope it works. You know, this software is written in current
pre-ANSI standard C :-).

Just in case we make our minds about discussing proposals for a new 
standard, I'd like to comment on the three objections raised about
the proposed construct:

(from last article of the Reference:)
> My only complaints about the labelled-loop/break-label solution are
> these:
> 	1) it's a goto anyway -- why fuss about it?  In particular,
> 	   why claim it is more ``structured'' than the same control-
> 	   flow with the horrible word ``goto'' in the code?

The fact that it is a harmless goto doesn't mean that you cannot write
harmful gotos. The reason for the change is that the proposed alternatives
work ONLY in a well predictable way, that the Human Reader may understand
without hesitation (somebody made this point clear just a few articles
ago).  The equivalence of the control flows is not under discussion, the issue
is probability of error under maintenance efforts. So it is not that one of
the EXAMPLES (i.e.: PARTICULAR CASES) is as clear as the other, it is that
under usual transformations one can go wild (the unrestricted), while the
other remains stable. Same reason makes 'exit <number of labels>' even more
atrocious than the 'goto-driven' version.
> 
> 	2) The notation suggested is itself counter-intuitive --
> 	   you are G*T*-ing to a label, but the label is up at
> 	   the top and you are going to the bottom (!?)
>
Huh? If you read 'exit Compute_Matrix_Product;' the same as you read
'goto Compute_Matrix_Product;' you are bound to have big trouble
reading C code anyway.  (Hmm, 'exit'? Well 'break' sounds awful, but 
it is too late too change it). So, to say it again:

break loop;	

doesn't g*t* label 'loop', it goes OUTSIDE the control scope of the
compound statement labelled 'loop', if one such exists. Moreover,
it doesn't go to the bottom (that function is reserved for the kin
of the current 'continue' statement, if that makes any sense at all;
that's why I said that it goes BEYOND the bottom).
> 
> 	3) do these solutions *really* cover everything?  Are you
> 	   going to leave setjmp/longjmp in the language?  They
> 	   can be transformed out too, you know...
> 
Now I think I have to agree with you 100%.  There are some unrestricted
transfers which I don't know how to reduce to anything sensible and keep
them portable/efficient. However, it doesn't detract from the proposal:  
These problems (setjmp/longjmp or other anomalies) don't occur nearly as 
often as the "I need to break three loops at once"-kind.  At least not in
normal everyday user-written code (as opposed to 'system-wizard hackeries').
It is possible to envision a restriction of the language (not even goto's)
to be used in non-time-critical non-hardware-dependent applications (is
there any application like that? probably isn't worth to code in C).

(Anecdote:
	       Something like that occurred in the old B1700 -- The system 
-if I remember the Dark Ages correctly- was mostly written in SDL, but user
applications were to be written in a more restricted, safety conscious 
subset called UPL, for User's Programming Language. No way, UPL was used
exactly by the same people who used SDL, the Rest of Them used COBOL. Sometimes
I still miss the B1726 and UPL. Loops were executed just once, with do ... end;
or they were REAL loops, like 'do forever ... end'. The idea of an 'exit' had 
to exist, but the name was equally horrid: 'undo'. Ahh, when 128k was an hell of
a lot of memory ... 
End of Anecdote).

But I'm not going to be the one to propose such a Fascist Idea as restricting
setjmp/longjmp for the Few Chosen Ones :-), the enlightened subscribers of
net.lang.c, of course.

Happy hacking,

Cesar Augusto  Quiroz Gonzalez

Department of Computer Science     {allegra|seismo}!rochester!quiroz
University of Rochester            or
Rochester,  NY 14627               quiroz@ROCHESTER

"Thou shalln't use O(n^3) algorithms, for they use to require three nested
you-know-whats and getting out of them may ask for a you-surely-guess-what"