Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site bmcg.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!sdcrdcf!sdcsvax!bmcg!bprice From: bprice@bmcg.UUCP Newsgroups: net.lang.c,net.lang,net.lang.pascal Subject: Re: X3J11 thoughts (function arguments) Message-ID: <1196@bmcg.UUCP> Date: Wed, 8-Aug-84 19:34:51 EDT Article-I.D.: bmcg.1196 Posted: Wed Aug 8 19:34:51 1984 Date-Received: Fri, 10-Aug-84 02:38:52 EDT References: <1036@research.UUCP>, <647@opus.UUCP> Organization: Burroughs Corporation, San Diego Lines: 75 As a 'charter member' of X3J9 and of the IEEE Pascal Standards committee, and thus of the Joint X3J9/IEEE Pascal Standards Committee, I recognize a few inaccuracies in Dunn's essay on the control variable standardization considerations. These are my own personal recollections and opinions, not representing anything (except as noted) that ANSI, X3, X3J9, or any IEEE body has passed on--but the record is available for anyone who finds fault in my recollection. >From: rcd@opus.UUCP >This quite strongly resembles something that happened in the Pascal >standardization effort: 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. > The standards committee >recognized (mostly correctly) that this can introduce some very odd >effects; it also makes loop optimization very difficult. As the requirement was originally stated, loop optimization was both easy and dangerous: there was no way, in practice, to verify that the control variable had not been altered. Without such verification, though, really strange bugs could have hidden out for long periods. > 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. If the new variable were given the type of another variable, say one having the same spelling for its identifier, other obscure bugs could be hidden. If the new variable were given a type derived from the types and values of the initial and final values, then a runtime determination of program validity would be required--if, say, the control variable were passed to a variable parameter. The other alternatives, and kludges to allow one of the above to work, were even more unacceptable to user and implementor alike on the committee. > However, this represented too >much of a change, See above. Breaking all existing for-statements or all existing compilers was indeed "too much of a change." > 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. The effect of this requirement is that full optimizability is achieved without breaking too many existing programs. The requirement is not difficult to implement in most pre-existing compilers, either. > Thus they removed the possibly useful effects of an >Algol 60 style of general use (which we also have in C, of course) - you >can't count with a var parameter or a global. Yet they failed to provide >the useful clarity and optimizability of a completely local ALGOL 68 style >of controlled variable. Since clarity is strictly subjective, I can't respond to that point in an objective fashion. In my experience, the clarity of the Pascal design is sufficient to be useful. The optimizability is no less than that of ALGOL 68, since the restrained control-variable approach of Pascal is, in the respects that matter, indistinguishable from the local approach. > 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. The response that I got, personally, to the compiler that I retrofitted was "thanks!". This is because every one of the programs that was "broken" by the change was wrong! The change pointed out lurking bugs, that hadn't been seen yet, in every instance. -- --Bill Price uucp: {decvax!ucbvax philabs}!sdcsvax!bmcg!bprice arpa:? sdcsvax!bmcg!bprice@nosc