Re: What is this

In article <1id2s8t.1bbglp8e5vewoN%nospam@xxxxxxxxxxxxx>,
nospam@xxxxxxxxxxxxx (Richard Maine) writes:
FX <coudert@xxxxxxxxxxxxx> wrote:

"C1263 (R1238) The function-name and each dummy-arg-name shall be
specified, explicitly or implicitly, to be scalar."

Hmm. So I see, and I agree with your analysis. Now I'm trying to
reconstruct where the material that I recall was from. Not having a lot
of luck with that. I looked at earlier versions of the standard; that
restriction also appears in f90 and f95. F77 doesn't have a simillarly
phrased restriction, but a careful reading of f77 translates to the same
thing. (In particular, the dummy argument is only allowed to have the
same name as a variable.... and in f77 an array does not count as a
variable).

Aha. I think I'm getting closer. look at the wording in 16.3 of f2003
(and similar words in f95 and f90). Those sound like the words I recall
debates about. In particular, they talk about having the same type and
type parameters as an entity of the same in the host would have, but
having no other attributes (DIMENSION being an attribute). Those are the
words that I think were interpreted to mean that the host could have an
array of that name (as long as the array was integer). I swear I recall
an example like that in some interp. But it might possibly have been an
example of some other construct entity such as a forall index or an
ac-implied-DO variable. I don't think those have a constraint like the
one you found for statement function dummy arguments.

I have to say that constraint doesn't seem to fit well with the material
in 16.3. From 16.3, it doesn't appear as though there is any way to
declare anything about the dummy argument except for its type (which
must be integer) and its type parameter. So that seems to make the
constraint nonsense, as you say. Sounds like an internal contradition in
the standard to me. Interp time?

It's not complete nonsense.

program z
real :: h(5), x(5) = 1.
real y
f(y) = y * x ! Invalid because f is implicitly an array via x.
h = f(2.)
end program z

Of course, F77 did not have array syntax. My immediate thoughts on
the constraint on dummy arguments is reference to array sections.

program z
real :: h(3), x(5) = 1.
f(x(2:4)) = 2 * x ! Invalid dummy arg (not to mention downright ugly).
h = f(x)
end program z

I suspect J3 in the F90 days was trying to avoid code like the above.

--
Steve
.

Relevant Pages

  • Re: Fundamental frequency -- limited resources
    ... Memory is the biggest ... > constraint, the processor horsepower is not as big a constraint. ... > The reality is that the array will actually hold values like ....4200, ... > keep thinking, "if I could just do an FFT and take the dominant freq, ...
    (sci.math.num-analysis)
  • Re: Caveat: Can One Dim Local Arrays Using Argument List Integers ??
    ... much time at all to find at least one example of an array that was not ... k is passed and used (as the dummy named n) ... make the actual and dummy declarations done the same way, ...
    (comp.lang.fortran)
  • Re: Display Array
    ... 'noentry', ... Informix will try to go to that field and provided its the last field ... > Subject: Re: Display Array ... > The normal way in Old 4GL was to have a dummy 'noenty' column at the ...
    (comp.databases.informix)
  • Re: Assumed-size arrays and intent(out)
    ... Our coding style standard says that an intent ... attribute must be provided for every dummy argument in new code. ... "undefining" parts of the Residuals array other than ... size dummy and passing an array element, you get sequence association, ...
    (comp.lang.fortran)
  • Re: how to use 1D array as a multidimensional array
    ... "If the dummy argument has the TARGET attribute and is an explicit-shape ... an assumed-size array, and the corresponding actual argument has the TARGET ... When execution of the procedure completes, the pointer association ... Passing a reference to an array descriptor (the reference part becomes ...
    (comp.lang.fortran)