quiroz@rochester.UUCP (Cesar Quiroz) (10/14/84)
(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"ron@brl-tgr.ARPA (Ron Natalie <ron>) (10/17/84)
> The fact that it is a harmless goto doesn't mean that you cannot write > harmful gotos. You are not going to legislate correct code by removing GOTO. I am trying to avoid drastically changing the language to add redundant features. If you want to design such a language, come up with some other standard but don't call it C. Go back to the PASCAL and ADA users where you belong. I still see that break to the n-th power is just as harmful as goto. Just look for the label. It's just as easy to hide a loop begin as a statement label. > 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'). Amen, but setjmp/longjmp is not C and shouldn't be in the spec. This is a machine dependant kludge. -Ron