Fortran Standards question: Dummy procedures with array arguments

[Janus Weil]

Dear Fortran experts,

please consider the following piece of code:


module m

contains

subroutine s1(a)
integer :: a(1:2)
end subroutine

subroutine s2(a)
integer :: a(2:3)
end subroutine

subroutine t1(a,b)
integer :: b
integer :: a(1:2*b+1)
end subroutine

subroutine t2(a,b)
integer :: b
integer :: a(2:2*b+2)
end subroutine

end module


program test
use m
implicit none

call foo(s2) ! *** legal?

call bar(t2) ! *** legal?

contains

subroutine foo(f)
procedure(s1) :: f
end subroutine

subroutine bar(f)
procedure(t1) :: f
end subroutine

end program


My question is: Are the two marked lines valid according to the recent
Fortran Standards? gfortran currently accepts both, while ifort
rejects them:

dummy_procedure.f90(30): error #7061: The characteristics of dummy
argument 1 of the associated actual procedure differ from the
characteristics of dummy argument 1 of the dummy procedure. (12.2)
[S2]
call foo(s2) ! *** legal?
-----------^
dummy_procedure.f90(32): error #7061: The characteristics of dummy
argument 1 of the associated actual procedure differ from the
characteristics of dummy argument 1 of the dummy procedure. (12.2)
[T2]
call bar(t2) ! *** legal?
-----------^


Some quotes from F08:

"12.5.2.9 Actual arguments associated with dummy procedure entities
If the interface of a dummy procedure is explicit, its characteristics
as a
procedure (12.3.1) shall be the same as those of its effective
argument, ..."

"12.3.1 Characteristics of procedures
The characteristics of a procedure are the classification of the
procedure as a
function or subroutine, whether it is pure, whether it is elemental,
whether it
has the BIND attribute, the characteristics of its dummy
arguments, ..."

"12.3.2.2 Characteristics of dummy data objects
The characteristics of a dummy data object are its type, its type
parameters
(if any), its shape, ...
If a shape, size, or type parameter is assumed or deferred, it is a
characteristic."

Combining the three statements above, F08 clearly demands that the
*shape* of
the argument should be the same (meaning that the bounds themselves
may
differ).

"1.3.128 shape
array dimensionality of a data entity, represented as a rank-one array
whose
size is the rank of the data entity and whose elements are the extents
of the
data entity"

However, there is one more sentence which seems to restrict this
further:

"If a type parameter of an object or a bound of an array is not a
constant
expression, the exact dependence on the entities in the expression is
a
characteristic."

Here, the standard talks explicitly about 'bounds of an array' and not
just the
'shape'.

Depending on how one reads this, it might mean two things:
1) for non-constant bounds, the bounds themselves have to match, not
only the
shape
2) for non-constant bounds, the shape expression (i.e. "upper bound
minus
lower bound") has to match, including the exact dependence on entities
in the
expression


Comments, anyone?

Cheers,
Janus

[glen herrmannsfeldt]

Janus Weil <ja...@gcc.gnu.org> wrote:

(snip)

> subroutine t1(a,b)
> integer :: b
> integer :: a(1:2*b+1)
> end subroutine

> subroutine t2(a,b)
> integer :: b
> integer :: a(2:2*b+2)
> end subroutine

(snip)

> subroutine foo(f)
> procedure(s1) :: f
> end subroutine

> subroutine bar(f)
> procedure(t1) :: f
> end subroutine

> My question is: Are the two marked lines valid according to the recent
> Fortran Standards? gfortran currently accepts both, while ifort
> rejects them:

From Fortran 2003:

"If proc-interface appears and consists of declaration-type-spec, it
specifies that the declared procedures or procedure pointers are
functions having implicit interfaces and the specified result type.
If a type is specified for an external function, its function
definition (12.5.2.1) shall specify the same result type and
type parameters."

It looks to me that the name in the PROCEDURE statement specifies
the return type of the function, not the argument type.

I could be wrong, but that is what it looks like to me.

-- glen

[Janus Weil]

> From Fortran 2003:
>
>   "If proc-interface appears and consists of declaration-type-spec, it
>    specifies that the declared procedures or procedure pointers are
>    functions having implicit interfaces and the specified result type.
>    If a type is specified for an external function, its function
>    definition (12.5.2.1) shall specify the same result type and
>    type parameters."

That quote does not apply here. The relevant one would be the
paragraph before the one you quote:

"If proc-interface appears and consists of interface-name, it specifies
an explicit specific interface (12.3.2.1) for the declared procedures
or procedure pointers. The abstract interface (12.3) is that specified
by the interface named by interface-name."

> It looks to me that the name in the PROCEDURE statement specifies
> the return type of the function, not the argument type.  

In the form used in my example, the PROCEDURE statement specifies not
only the return type, but the *whole* interface, including arguments.

If you don't like PROCEDURE statements, here is a completely
equivalent example using INTERFACE blocks (i.e. pure F95):


module m

contains

subroutine s2(a)
integer :: a(2:3)

end subroutine

subroutine t2(a,b)
integer :: b
integer :: a(2:2*b+2)
end subroutine

end module

program test
use m
implicit none

call foo(s2) ! *** legal?

call bar(t2) ! *** legal?

contains

subroutine foo(f)

interface
subroutine f(a)

integer :: a(1:2)
end subroutine

end interface
end subroutine

subroutine bar(f)
interface
subroutine f(a,b)

integer :: b
integer :: a(1:2*b+1)
end subroutine

end interface
end subroutine

end program


Cheers,
Janus

[glen herrmannsfeldt]

Janus Weil <ja...@gcc.gnu.org> wrote:

>> From Fortran 2003:
>>
>>   "If proc-interface appears and consists of declaration-type-spec, it
>>    specifies that the declared procedures or procedure pointers are
>>    functions having implicit interfaces and the specified result type.
>>    If a type is specified for an external function, its function
>>    definition (12.5.2.1) shall specify the same result type and
>>    type parameters."

> That quote does not apply here. The relevant one would be the
> paragraph before the one you quote:

> "If proc-interface appears and consists of interface-name, it speci???es
> an explicit speci???c interface (12.3.2.1) for the declared procedures
> or procedure pointers. The abstract interface (12.3) is that speci???ed

> by the interface named by interface-name."

(snip)

> If you don't like PROCEDURE statements, here is a completely
> equivalent example using INTERFACE blocks (i.e. pure F95):

(snip)

In that case, I suspect that it is required to be the exact
same interface. Note that in many cases one can't use an
interface that looks the same, it must actually be the same.

Try the original program with the same dimensions, including
upper and lower bounds, in all cases. See if you still get
the error message.

-- glen

[Richard Maine]

Well, for a start, the whole para you cited is irrelevant because the
proc-interface does not consist of a declaration-type-spec in this case.

I'm afraid that I'll punt on answering the original question here. I
pretty much agree with Janus's argument that the bounds should not
matter as long as the shape is right. But then he cites that horrid
requirement in the standard "If a type parameter of an object or a bound

of an array is not a constant expression, the exact dependence on the

entities in the expression is a characteristic." I've never actually
understood precisely what that requirement says (and I suspect that
neither did whoever wrote it). There has been (at least) one
interpretation request about the meaning of that requirement. If I
recall correctly, I didn't find the answer to the interp to be any
clearer than the original. That's without even getting into why it talks
about bounds instead of shape (presumably because shape is never
specified explicitly - it is derived from the bounds).

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[Richard Maine]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> Janus Weil <ja...@gcc.gnu.org> wrote:

> > "If proc-interface appears and consists of interface-name, it speci???es
> > an explicit speci???c interface (12.3.2.1) for the declared procedures
> > or procedure pointers. The abstract interface (12.3) is that speci???ed
> > by the interface named by interface-name."
>

> In that case, I suspect that it is required to be the exact
> same interface. Note that in many cases one can't use an
> interface that looks the same, it must actually be the same.

You need to look up the definition of "interface". There is one, and it
isn't what you appear to think. You seem to be confusing "interface"
with "interface body" or something like that. They are not the same
thing. Yes, the difference matters. An interface body provides a means
of specifying an interface, but the interface body can and often does
have things in it that are not part of the interface. Heck, the standard
specificaly allows an interface body to have declarations that have
nothing at all to do with the interface (in order to facilitate making
interface bodies by copying declarations from procedures).

Specifically, from f2003, 12.3

"The procedure's interface consists of its abstract interface,
its name, its binding label if any, and the procedure's generic
identifiers."

Note that there is nothing in there about bounds. In case you think it
might be hiding in the definition of "abstract interface", that's a few
lines further down as

"An abstract interface consists of procedure characteristics and the
names of dummy arguments."

Janus already quoted the definition of procedure characteristics.

I might add also that, no, there is no requirement that interfaces be
declared with respect to the same interface body. The requirement that
you are thinking of is very specific to type declaration. See the
section in the standard on "determination of derived types". That's
4.5.1.3 in f2003 (or it is one of the things that I happen to think is
explained more clearly in the book I'm a coauthor on; my opinion on that
is probably biased as I mostly wrote that bit). There is no such
requirement for procedure interfaces. It wouldn't actually make sense
for there to be such a requirement as it would completely nullify much
of the point of interface bodies in many cases.

So no, I don't think this does anything to address the OP's question.

[Janus Weil]

Dear Richard,

> I'm afraid that I'll punt on answering the original question here. I
> pretty much agree with Janus's argument that the bounds should not
> matter as long as the shape is right.

thanks for your feedback! If you are right, this means that at least
ifort's rejection of my first example ("call foo(s2)") is a bug.

> But then he cites that horrid
> requirement in the standard "If a type parameter of an object or a bound
> of an array is not a constant expression, the exact dependence on the
> entities in the expression is a characteristic." I've never actually
> understood precisely what that requirement says (and I suspect that
> neither did whoever wrote it).

Well, yeah. To me, the logical continuation of the constant-bounds
case would be to require that the exact dependence of the *shape* on
any entities appearing should be the same (maybe this is actually what
is meant here), and I see no reason why that requirement should be
more strict than in the constant-bounds case. I plan to implement such
a check in gfortran, and maybe this variant is what I will start with
(since it is slightly more tolerant and will not reject any possibly
valid cases).

Besides, it is not entirely clear whether "the exact dependence"
should be understood in the mathematical or the literal sense (i.e.
are mathematical transformations allowed or not?). However, this is
probably mostly academic and hard for a compiler to check in general.

We recently introduced a check like this for string lengths in
gfortran, and ended up giving only warnings for the more complicated
cases that the length *might* be different (but could well be
mathematically equal).

> There has been (at least) one
> interpretation request about the meaning of that requirement.

Could you please be so kind to point me to this interpretation request
(hoping that it is available online)?

> That's without even getting into why it talks
> about bounds instead of shape (presumably because shape is never
> specified explicitly - it is derived from the bounds).

Apparently the same formulation is already present in F95 and hasn't
changed significantly in neither F03 nor F08.

Cheers,
Janus

[Richard Maine]

Janus Weil <ja...@gcc.gnu.org> wrote:

quoting me:

> > But then he cites that horrid
> > requirement in the standard "If a type parameter of an object or a bound
> > of an array is not a constant expression, the exact dependence on the
> > entities in the expression is a characteristic." I've never actually
> > understood precisely what that requirement says (and I suspect that
> > neither did whoever wrote it).
>
> Well, yeah. To me, the logical continuation of the constant-bounds
> case would be to require that the exact dependence of the *shape* on
> any entities appearing should be the same (maybe this is actually what
> is meant here),

I *THINK* that's the right answer. See the attached interps. But I'm not
willing to stand behind that; I find the interp answers too unclear.

> Besides, it is not entirely clear whether "the exact dependence"
> should be understood in the mathematical or the literal sense (i.e.
> are mathematical transformations allowed or not?). However, this is
> probably mostly academic and hard for a compiler to check in general.

Rereading the interps, I think that they just mean that the same values
have to result. For example m+m has the same "exact dependence" on m as
does 2*m. Again, I'll not promise to be reading them correctly. I'm
pretty sure, though that compilers aren't required to catch this kind of
error anyway; I think it is just telling users that they better not lie
to the compiler in a way that will make it do things wrong. That is,
there ought to be the same result whether the compiler evaluates the
expression based on what it sees in the interface block versus what is
in the procedure. If the user writes an interface block with an
expression that gives the wrong answer, he shouldn't be surprised if
things screw up.

> > There has been (at least) one
> > interpretation request about the meaning of that requirement.
>
> Could you please be so kind to point me to this interpretation request
> (hoping that it is available online)?

Oh dear. I should have figured you'd ask that... (after spending a bit
of time searching, as I'm not at all current on this stuff). Below are
copies of the 3 related interps I found.

I think these are the "final" word in that they are all tagged as being
passed by WG5. You have to be careful in citing interp answers; just
because an answer appears in an interp doesn't mean that the committee
actually voted on that answer. It might mean that only the author of the
paper thought it was a good answer. I swear there are cases where even
the author thought it a bad answer, but proposed it just to incite
discussion about how that couldn't be right. But these look to be done.

These stuck around for about a decade and a half before getting
answered. Note the original dates of 1992 on interps f90/049 and
f90/070, and note that the answers didn't pass a WG5 ballot until 2005.
I'm still not convinced that they fully answer the questions. I'm
particularly puzzled by the answer to 017. It sure looks to me like a
"blowoff" answer that just uses the distinction between "constant" and
"initialization expression" as an excuse to wipe the interp request from
the table without bothering to answering the actual question. Maybe I
missed something.


[excerpted from] J3/04-006Ar1.txt

----------------------------------------------------------------------

NUMBER: 000017
TITLE: Characteristics of an array function result
KEYWORDS: Characteristics, function
DEFECT TYPE: Interpretation
STATUS: Passed by WG5 ballot

Sections 12.2.1.1 and 12.2.2 of the Fortran 95 standard define rules
for dummy arguments and function returns in the presence of explicit
interfaces that allow array bounds expressions to be evaluated on
either the calling side or the called side of a call. The
interpretation provided for RFI 000049 on the X3J3 website clarifies
and reinforces the conditions that permit evaluation on either side
of the call. The erratum published in the same file for RFI 000070
changes the semantics of dummy arguments. The erratum does not
explicitly mention function results, but it might be considered to
imply a similar change to the semantics of function results.

The erratum provided for RFI 000070 refers to altered text for the
interpretation provided for RFI 000049. The version of the
interpretation that appears in the file on the X3J3 website does not
contain the altered text.

The definition of characteristics of function results as stated in
Section 12.2.2 of the Fortran 95 standard permits more efficient
implementation of array-valued functions, at least for some
architectures, than the definition implied by the erratum provided
for RFI 000070. For Sun, it is more efficient for the calling
routines to allocate space for array results than to have the called
routines allocate the space. In order for the calling routine to
allocate space for an array result, it must know the size of the
array. To determine the size of the array, it must evaluate the
array bounds expressions given in the explicit interface for the
function.

Section 12.2.2 of the Fortran 95 standard requires the values of the
nonconstant bounds expressions given in an explicit interface to be
the same as the values of the bounds expressions given in the
corresponding function definition. Thus, the values of the
nonconstant bounds expressions used to determine the size of the
array result can be passed to the called routine, avoiding any need
for the called routine to re-evaluate those expressions. Because
Fortran 95 allows user-defined routines to appear in bounds
expressions, evaluating the bounds expressions more than once per
call could prove inefficient and confusing.

The change implied by the erratum provided for RFI 000070 would
remove the nonconstant bounds expressions from the characteristics of
function results. The shape would still be a characteristic, but the
same shape can be produced by many different values of the bounds
expressions. Thus, the values of the nonconstant bounds expressions
used in the called routine may differ from the values of the
corresponding expressions in the explicit interface.

For example, consider the explicit interface

INTERFACE
FUNCTION FOO(F, G, H)
INTERFACE
PURE INTEGER FUNCTION F()
END FUNCTION
PURE INTEGER FUNCTION G()
END FUNCTION
PURE INTEGER FUNCTION H()
END FUNCTION
END INTERFACE
CHARACTER*(F()) FOO(G():H())
END FUNCTION
END INTERFACE

The definition given in Section 12.2.2 of the Fortran 95 standard
requires the values of the length and bounds expressions in the
interface to be the same as the values of the corresponding length
and bounds expressions in the function definition.

Under the definition implied by the erratum provided for RFI 000070,
the shapes must match, but the values of the nonconstant bounds
expressions need not. Thus, the function definition might be

FUNCTION FOO(F, G, H)
INTERFACE
PURE INTEGER FUNCTION F()
END FUNCTION
PURE INTEGER FUNCTION G()
END FUNCTION
PURE INTEGER FUNCTION H()
END FUNCTION
END INTERFACE
CHARACTER*(F()) FOO(G()-1:H()-1)
. . .
END FUNCTION

In this case, the values of the bounds expressions used in the called
routine must be the values of the expressions specified in the
function definition, not the values of the expressions specified in
the interface block.

QUESTION:

If a bound of a function result array is not a constant expression,
is the exact dependence on the entities in the expression a
characteristic of the function result?

ANSWER:

No. According to Corrigendum 1, the correct statement is now:

"If a bound of a function result array is not an initialization

expression, the exact dependence on the entities in the expression is

a characteristic of the function result."

EDITS: None

REFERENCES: 95-006a, F90/000027, F90/000049 & F90/000070, 04-295,
N1416 (Corrigendum 1).

SUBMITTED BY: Robert Paul Corbett

HISTORY: 98-114 submitted
04-313 m168 Passed J3 meeting vote
04-417r1 m170 Passed by J3 letter ballot #8
05-180 m172 Passed by WG5 ballot N1617

----------------------------------------------------------------------

NUMBER: F90/000049
TITLE: Characteristics of function results
KEYWORDS: characteristics, function result, ENTRY statement, exact
dependence, association - partial, association - entry
DEFECT TYPE: Interpretation
STATUS: Passed by WG5 ballot

QUESTION:

Given a character function with an ENTRY statement, both results must
have the same characteristics or be scalars without the POINTER
attribute and have identical length. Therefore:

FUNCTION FUN(M,N)
CHARACTER (LEN=M+N)::FUN,ENT
...
ENTRY ENT(M,N)
...
END FUNCTION

is standard conforming.

Question 1:
FUNCTION FUN(M,N)
CHARACTER (LEN=M+N)::FUN
CHARACTER (LEN=M+N)::ENT
...
ENTRY ENT(M,N)
...
END FUNCTION

Is the code above standard conforming?

Question 2:
FUNCTION FUN(M,N)
CHARACTER (LEN=M+N)::FUN
CHARACTER (LEN=N+M)::ENT
...
ENTRY ENT(M,N)
...
END

Is the code above standard conforming?

Question 3:
FUNCTION FUN(M)
CHARACTER (LEN=M+M)::FUN
CHARACTER (LEN=M*2)::ENT
...
ENTRY ENT(M)
...
END

Is the code above standard conforming?

Question 4: What is the meaning of the phrase "the exact dependence
on the entities" in section 12.2.2?

ANSWER:

Answer 1. Yes
Answer 2. Yes
Answer 3. Yes
Answer 4. The sentence containing the phrase "the exact dependence
on the entities" in section 12.2.2 is intended to convey that in
those cases where the shape or character length type parameter is not
constant, the corresponding characteristic of the function result is
not a value but the way the value is determined when the procedure is
invoked.

Discussion: Only the mapping from program state to value is
significant, not the particular form in which that mapping is
expressed.

In question 3, for example, it is a characteristic of FUN and ENT
that their lengths are twice the value of M. It is not required that
the expressions of this mapping be identical, only that they yield
the same results. Thus, twice the value of M could be expressed as
M+M for FUN and as M*2 for ENT.

The phrase "the exact dependence on the entities in the expression is
a characteristic" is used to give the processor the freedom to
evaluate lengths and bounds in any convenient manner. Since the
characteristics must be the same, the phrase implies, as a minimum,
that the expressions be algebraically equivalent and use the same
variables. In an example such as:

FUNCTION FUN(M)
CHARACTER (LEN=M)::FUN
CHARACTER (LEN=M + 0*K)::ENT
...
ENTRY ENT(M, K)
...
END

FUN and ENT do not have the same characteristics since their
dependence on "K" is different. Indeed, if on entry to FUN the
length of FUN or ENT were evaluated using the expression for the
length of ENT the evaluation would fail since K is not associated
with a value.

Clearly, it can be extremely difficult to determine on a static basis
whether two expressions of a mapping are consistent, and there is no
requirement in the standard that this be done. It would be possible
to check during execution that the values expressed are identical
each time such a procedure is invoked, but it is expected that a more
typical application of this requirement would be to assume that it
has been met and use one expression of this mapping as the basis for
computing attributes of all of the result variables.

REFERENCES: ISO/IEC 1539:1991 (E) section 12.2.2 & 14.6.3.3

EDITS: None

SUBMITTED BY: Y. Yoshida, X3J3/92-051 (121-ADT-11) pp.-13

HISTORY: 92-109A m121 Approved 19-0
92-313 m123 response to ballot comments and
approved by uc
93-105 Revised in response to ballot comments
93-152 m125 New edit, rejected
94-059 m128 New edit,
94-252 m130 New response without edits, approved u.c.
94-306 m131 X3J3 ballot approved 18-1
95-044 m132 WG5 ballot failed
006Ar1 m168 Passed by J3 meeting vote as in 02-006Ar1
04-417r1 m170 Passed by J3 letter ballot #8
05-180 m172 Passed by WG5 ballot N1617

----------------------------------------------------------------------

NUMBER: F90/000070
TITLE: Characteristics specified by interface bodies
KEYWORDS: characteristics, array bounds, array shape, function result
DEFECT TYPE: Interpretation
STATUS: Passed by WG5 ballot

QUESTION:

Section 12.3.2.2 indicates that an interface body specifies all of a
procedure's characteristics and that the characteristics must be
consistent with those in the procedure definition. Are the following
code fragments standard conforming?

(a) PROGRAM FRED
INTERFACE
SUBROUTINE SUB (ARR,J)
INTEGER ARR(1:)
END SUBROUTINE
END INTERFACE
INTEGER ARR(10)
CALL SUB(ARR,2)
END PROGRAM

SUBROUTINE SUB(ARR, J)
INTEGER ARR(J:)
...
END SUBROUTINE SUB

(b) FUNCTION C1( )
CHARACTER(*) C1
...
END FUNCTION C1
FUNCTION C2(N)
CHARACTER(N) C2
...
END FUNCTION C2

SUBROUTINE CALLER( )
INTERFACE
FUNCTION C1( )
CHARACTER(*) C1
END FUNCTION
FUNCTION C2(N)
CHARACTER(2) C2
END FUNCTION
END INTERFACE
CHARACTER(5) CC
CC=C1( )//C2(2)

ANSWER:

(a) This example is standard conforming.

(b) This example is not standard conforming.

Discussion:

(a) 12.2.1.1 states that the characteristics of a dummy data object
include its shape, and that if the shape is assumed then that is a
characteristic. Section 2.4.5 states that the shape of an array is
determined by its rank and extent in each dimension (but not by its
bounds, 5.1.2.4.2). Both the interface block for SUB and the
definition of SUB describe the shape of ARR as assumed, so they are
describing the same shape, and the program is standard conforming.

(b) Section 12.2.2 states that the characteristics of a function
include whether or not the function result value is a character of
assumed length. So the interface body for function C1 must indicate
that C1 is of assumed length. However, item (3) in 5.1.1.5 indicates
that scoping units that invoke an external character function of
assumed length must have access to a declaration of the function name
with a length type parameter value other than *. This is explained in
Note 5.6, (which has been removed in Fortran 2003).

In addition, the interface for C2 does not conform to the standard as
the length of C2 specified as 2 is not consistent with the length
specified as N within the function definition.

REFERENCES: ISO/IEC 1539:1991 (E) sections 2.4.5, 5.1.1.5, 5.1.2.4.2,
12.2.1.1, and 12.2.2.

EDITS: None

SUBMITTED BY: Graham Barber (a), Janice Shepherd (b)

HISTORY: 92-264 Question (a) originally posed
92-46 Question (b) originally posed in e-mail
ui 48 (jw note)
92-283 Response proposed
m123 Approved by unanimous consent
93-018 Response questioned by John Reid in
93-103 Revised response proposed
m124 Approved by unanimous consent
93-111 m125 ballot, return to subgroup, Leonard comment,
coordinate with 0000049?
94-060 m128 New edit in F90/000049 referenced
04-295 m168 Passed by J3 meeting vote
04-417r1 m170 Passed by J3 letter ballot #8
05-180 m172 Passed by WG5 ballot N1617

----------------------------------------------------------------------

[Janus Weil]

> > > There has been (at least) one
> > > interpretation request about the meaning of that requirement.
>
> > Could you please be so kind to point me to this interpretation request
> > (hoping that it is available online)?
>
> Oh dear. I should have figured you'd ask that... (after spending a bit
> of time searching, as I'm not at all current on this stuff). Below are
> copies of the 3 related interps I found.

Thanks a lot for your efforts. I'll look through them soon ...

Cheers,
Janus

[Janus Weil]

> > > But then he cites that horrid
> > > requirement in the standard "If a type parameter of an object or a bound
> > > of an array is not a constant expression, the exact dependence on the
> > > entities in the expression is a characteristic." I've never actually
> > > understood precisely what that requirement says (and I suspect that
> > > neither did whoever wrote it).
>
> > Well, yeah. To me, the logical continuation of the constant-bounds
> > case would be to require that the exact dependence of the *shape* on
> > any entities appearing should be the same (maybe this is actually what
> > is meant here),
>
> I *THINK* that's the right answer. See the attached interps. But I'm not
> willing to stand behind that; I find the interp answers too unclear.

Ok, after carefully reading all three interpretation requests, I would
conclude that this is indeed the right answer: Also for non-constant
bounds, only the shape has to match, not the bounds themselves. There
is one sentence in the first request which makes this pretty clear:

> Under the definition implied by the erratum provided for RFI 000070,
> the shapes must match, but the values of the nonconstant bounds
> expressions need not.

That is just the kind of statement I was looking for.

> > Besides, it is not entirely clear whether "the exact dependence"
> > should be understood in the mathematical or the literal sense (i.e.
> > are mathematical transformations allowed or not?). However, this is
> > probably mostly academic and hard for a compiler to check in general.
>
> Rereading the interps, I think that they just mean that the same values
> have to result. For example m+m has the same "exact dependence" on m as
> does 2*m.

Right. The second request is rather clear on that. However, the one
point that I find rather strange is:

> CHARACTER (LEN=M)::FUN
> CHARACTER (LEN=M + 0*K)::ENT
> ...

> FUN and ENT do not have the same characteristics since their
> dependence on "K" is different.

I can follow the logic that is used to justify this, but I don't find
it very convincing. In real life, the "0*K" will be optimized away by
the compiler, and that's also what my brain does when I see such an
expression. If one argues that algebraic transformations are allowed,
then "0*K" will be transformed into "0".

But anyway, this is a completely academic corner case, and anyone who
writes such code in a real-world application will hopefully get what
he deserves.

> I'm pretty sure,
> though that compilers aren't required to catch this kind of error anyway

As I said, it will be pretty hard to have an implementation which
really catches all cases. gfortran will soon be able to catch at least
the simple ones, and I don't think it's worth the effort to catch all
the harder ones.


Thanks again for digging out the interpretation requests. Btw, once
such a request is answered, wouldn't it be a good idea to change the
wording in the next version of the standard, in order to make things
clearer? If it was passed in 2005, why hasn't it been integrated into
F08?

Cheers,
Janus