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.