On 2015-09-05 5:12 AM,
paul.rich...@gmail.com wrote:
> On Thursday, 3 September 2015 12:58:01 UTC+2, Ian Harvey wrote:
>> On 2015-09-03 5:10 PM, Andrew Baldwin wrote:
...
Upon encountering the assignment I expect the compiler to have a list of
... lets call them "specific interfaces" - procedures and specific
bindings - that sit behind the assignment generic identifier, whether
those bindings are acquired from Fortran 95 style stand-alone interface
blocks, or from generic bindings in the declared types of the left hand
side or right hand side parts of the assignment statement (the list can
consider generic bindings from any type in scope, but they will always
be eliminated next).
I then expect the compiler to first consider the non-elemental specific
interfaces and see if it can find a match on type, kind and rank of the
actual arguments (and pointer vs allocatable too, in F2008), noting that
the right hand side argument is to be taken as a parenthesised
expression. Because of the rules around generic disambiguation, there
can be at most one such non-elemental specific interface.
In this case I expect the compiler to get a match with the specific
procedure REALLOC_ASGN (which matches on type, kind and rank). The
compiler should then consider the assignment to be defined assignment,
and should then map the left and right hand sides of that assignment
statement to that specific procedure, and then use that procedure to
execute the assignment. Here that procedure [always] reallocates the
actual argument that corresponds to the left hand side of the assignment
to match the right hand side, but note this is not intrinsic assignment,
this is defined assignment directed by a procedure.
Here, actual argument attributes other than type, kind and rank are
consistent with that specific procedure - namely that the left hand side
thing in the assignment is allocatable. If the left hand side thing in
the assignment statement was not allocatable, I would expect the
compiler to issue a diagnostic.
~~~
If there was no non-elemental specific procedure in the list of specific
interfaces sitting behind the generic identifier for assignment (so lets
pretend no REALLOC_ASGN in the code above), then I would expect the
compiler to consider any elemental specific interfaces, and see if it
can find a match on type, kind and
rank-consistent-with-eleemtal-reference (actual argument scalars or
array, but if more than one array, then all arrays must have same rank).
Because of the rules of generic disambiguation, there can be at most
one such elemental specific interface.
This is where I think the standard has an error - in that it appears to
also require conforming arguments, which implies a runtime decision in
the general case. I think this very inconsistent with how generic
resolution works elsewhere in the language. "Conforming" in 7.2.1.4
5(b) should be whatever formal term means
rank-consistent-with-elemental-reference. I think alternatives, such
as requiring a runtime test of whether arguments are conformable to work
out whether intrinsic or defined assignment was in play, or
intrinsic-by-default-unless-it-is-conformable-at-compile-time (note the
language has no explicit concept of compile time) to be a path to madness.
Given my view of what the standard meant to say, and assuming that
REALLOC_ASGN was removed from the example above, then I would expect the
compiler to find a match against the ASGN_A specific binding of A_TYPE.
It would then interpret the assignment statement as defined assignment
- a reference to a procedure with the interface of that specific
binding, the actual procedure referenced depends on the dynamic type of
the passed object, which in this case is simply ASGN_A (the thing with
the matching binding is not polymorphic so its dynamic type matches its
declared type).
At that point the code would then be non-conforming, as the arguments to
the specific procedure are not conformable. In the general case this
could only be detected at runtime, and conforming Fortran processors are
not required to issue a diagnostic for this sort of programming error.
Whether a compiler detected this at compile time, or detected this at
runtime, or just merrily carried on trashing memory somewhere, or ran
off with your teenage daughter, depends on the compiler, supporting
runtime and libido of its developers.
Because the compiler would interpret the assignment as defined
assignment there would be no reallocation on assignment (which is an
intrinsic assignment feature). Given the specific interface was
elemental, there could also be no possibility of the user manually
coding something equivalent to reallocation on assignment, as for the
previous non-elemental matching case - dummy arguments of elemental
procedures cannot be allocatable.
~~~
If there was both no type, kind and rank matching non-elemental specific
interface and no type, kind and elemental-consistent-rank matching
elemental specific interface, then I expect intrinsic assignment to be
used. In this hypothetical case (pretending both the REALLOC_ASGN
specific procedure and the ASGN_A specific binding were deleted from the
example) that would invoke reallocation of the left hand side to match
the shape of the right hand side, as the original shape of the left hand
side does not match the shape of the right hand side.
There you go - it might be a bit long, but that's what I think should
happen, perhaps bar the teenage daughter bit.