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