X3J11 thoughts (Standardization)

Dick Dunn rcd at opus.UUCP
Thu Aug 16 19:03:47 AEST 1984


Responding to Bill Price, on the effects of standardization wrt the Pascal
`for' statement.  Bill offered to correct a few inaccuracies.  >>=me, >=Price.
>>In Pascal, the controlled variable of a `for'
>>statement was originally just a variable.  
>Although the original language definition required "The control variable...
>must not be altered by the repeated statement."  This requirement was clarified
>and used in the development of the standard.

Bill is right, but there's nothing inaccurate about what I said--the
controlled variable WAS just a variable.  The requirement about not
altering the controlled variable quite naturally needed to be clarified,
since it was impossible to detect in any reasonable fashion as originally
stated.
 
>>                                                         The "ideal"
>>solution would have been to have the controlled variable be local to, and
>>declared by, the `for' statement itself.  
>The alternative ways of typing the control variable made this solution far
>from ideal.  If the type were given in the for-statement, then all for-
>statements would have been broken...<<and other difficulties>>

I didn't mean to imply that this would have been a viable approach for an
existing language.  It wouldn't.  What I meant was an "ideal" way to do
things in a new language (according to certain goals).  Standards efforts
(except for Ada:-) are not supposed to develop new languages.  It IS
possible to surmount the difficulties of declaring the controlled variable
implicitly at the opening of the for-loop.  As I said before, see ALGOL 68
for an example.

>>                  SO they took a middle ground and required only that it be
>>a local variable. 
>Not quite so--the 'middle ground' requires it to be a local variable, to be 
>sure, but it also requires that there be no alteration of it (e.g., 
>assignment to it) in any procedure which the forstatement can call, and that
>the forstatement itself may not alter it...

This IS a middle ground between making the controlled variable something
which is entirely owned by the for-statement and unalterable (i.e., not
really a variable, in the ALGOL 68 style) and something which is a general
variable (in the Algol 60 style or conventional C usage).  It is not a
middle ground on the alteration issue.  The original Pascal was MORE
permissive here--it only required that there be no alteration of the
controlled variable within the loop.  The standard (unless it changed since
the last time I saw it; Bill may correct me) requires, in effect, that
there be no potential for alteration of the variable--e.g., that it not be
passed as a VAR parameter.  The standard is more restrictive in principle
but in practice it hurts very little here, and it makes violations easily
detectable at compilation time.  I find it hard to fault this aspect of the
standard.

>>                         Finally, they broke some programs in the process
>>of making the change.
>But the number of programs broken was the smallest that we could manage.  Any
>other approach would have broken more...

This is emphatically false.  Had they not changed the definition to
restrict the controlled variable to a variable local to the procedure in
which the for statement occurs, fewer programs (probably none) would have
been broken as a result of the for-statement definition in the standard.
And if a couple of my programs hadn't been among the ones that got broken,
I wouldn't be so pissy about it.  But they did break, and the fixes weren't
entirely trivial.  My original point was about the occasional halfway-fix
that sometimes comes out of standardization efforts, and I stand by it.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
	...Never attribute to malice what can be explained by stupidity.



More information about the Comp.lang.c mailing list