Re: Redefining a numeric constant in Fortran (Was Re: why are some types immutable?)

From: James Giles (jamesgiles_at_worldnet.att.net)
Date: 01/17/05 

Date: Mon, 17 Jan 2005 03:01:04 GMT

beliavsky@aol.com wrote:
> Roy Smith wrote (in comp.lang.python):
>
>> Believe it or not, in some early versions of Fortran, numbers were not
>
>> immutable! I forget the exact scenario, but if you did something like:
>
>> subroutine munge (i)
>> i = 3
>> return
>
>> and then in your main program did:
>
>
>> j = 7
>> call munge (7)
>> write (6, 11) j
>> 11 format ('j = ', i6)
>
>> it would print 3! The problem is that numerical constants were interned
>> (i.e. in the main program, there was only a single 7 stored in memory,
...
> Was this (the ability to redefine the value of '7') ever really true of
> Fortran, or a particular Fortran compilers?

This was always illegal. In the FORTRAN 66 standard document
it says (§8.3.2):

   If an actual argument corresponds to a dummy argument that is
   defined or redefined in the referenced subprogram, the actual
   argument must be a variable name, an array element name, or
   an array name. [...]

All Fortran standards have required that actual arguments be
definable if they are associated with dummy arguments that
change during the execution of the procedure. It is not, however,
a violation that's required to be detected or reported by compliant
implementations. So, programs that violate the requirement are
subject to arbitrary treatment by the implementation - including
starting WWIII, but more often , the above mentioned strange
behavior.

I've long advocated that if the actual argument is a not definable,
an anonymous copy should be created that is associated with
the dummy argument. The procedure could then change it as
desired. The anonymous copy is then ignored upon return.
This is the behavior required for dummy arguments that have
the VALUE attribute in the F2003 standard. But the rule I just
stated would give the control to the caller of the procedure. 

-- 
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

Relevant Pages

  • Re: Fortran arguments by reference
    ... where the actual argument passed was a procedure pointer. ... If an outer procedure takes a dummy ... Isn't more correct that the Fortran standard does not specify the argument ... In VMS, arguments may be passed by reference, by value, or by descriptor. ...
    (comp.lang.fortran)
  • Re: Several questions about character C binding
    ... from 15.2.6 says that the number of Fortran "dummy arguments" and the ... its respective standard) must be the same: ... Again and again we see questions about interfacing Fortran character ... compiler knows, be associated with an assumed length dummy argument, ...
    (comp.lang.fortran)
  • F2003 standard question: Generic resolution and passing a "string" to a character(len=1), dimension
    ... array-valued ucs4-kind dummy argument is invalid Fortran 2003 and should ... This also holds for Fortran ... END MODULE modtest ... CALL One(chrScalar) ...
    (comp.lang.fortran)
  • Re: Basic question on local variable
    ... which however is only available in Fortran 2003 and ... You may only use the VALUE attribute if the argument is not an array ... So, in fact, the better solution is to declare the dummy ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: Ambiguous interfaces in gfortran -- whos right?
    ... are not as cool as they could be in Fortran. ... A procedure in a module could have an implicitly typed dummy ... Is this dummy a variable of the implicit type, ... actual argument to another subroutine or function? ...
    (comp.lang.fortran)