X3J11 thoughts (function arguments)

[bprice at bmcg.UUCP]

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 at 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 at nosc