Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site opus.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!zehntel!hplabs!hao!cires!nbires!opus!rcd
From: rcd@opus.UUCP (Dick Dunn)
Newsgroups: net.lang.c,net.lang,net.lang.pascal
Subject: Re: X3J11 thoughts (Standardization)
Message-ID: <703@opus.UUCP>
Date: Thu, 16-Aug-84 05:03:47 EDT
Article-I.D.: opus.703
Posted: Thu Aug 16 05:03:47 1984
Date-Received: Sun, 19-Aug-84 01:29:44 EDT
References: <1036@research.UUCP>, <647@opus.UUCP> <1196@bmcg.UUCP>
Organization: NBI, Boulder
Lines: 66

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...<>

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.