(j3.2006) request for interpretation

[Van Snyder]

On Fri, 2008-04-04 at 15:41 -0500, Kurt W Hirchert wrote:
> Consider the following program fragment:
> 
>       MODULE M
>         INTERFACE F
>           FUNCTION FR(X)
>             REAL X
>           END FUNCTION
>           FUNCTION FI(I)
>             INTEGER I
>           END FUNCTION
>         END INTERFACE
>       CONTAINS
>         SUBROUTINE SUB
>           INTEGER F(100)
>           ...
>           X1 = F(1.0)     !legal?
>           X2 = F(1)       !legal? if so, does it reference function or array?
>           ...
>         END SUBROUTINE
>       END MODULE
>   
> As I see it, the relevant sentence from the second paragraph is "A
> name that appears in the scoping unit as <long list of usages
> including entity declaration> is a local identifier in the scoping
> unit and any entity of the host that has this as its nongeneric name
> is inaccessible by that name by host association."  Thus the
> declaration of F in SUB would block access to F in M if F were
> nongeneric, but since it is generic, both Fs should be accessible in
> SUB.  [I am applying essentially the same logic that was being used to
> assert that both versions of SUBR should be accessible in S of Robert
> Corbett's example.]  In theory, one could write a compiler that
> handled the assignment to X1 (although I doubt any existing compiler
> does so), but for the assignment to X2 we have neither an analog of
> 12.4.4.1 to tell us how to interpret the reference to F nor an analog
> of 16.2.3 to say it is not allowed.

1986 was the year I first urged X3J3 to adopt accessors, which are
functions or updaters depending on how they're referenced.  An updater
is a procedure whose references look like function references, but that
works the opposite of a function (it "absorbs" a value instead of
producing one), and whose references could appear only in variable
definition contexts.  I also urged that a function-like syntax ought to
be used for structure component references.  This argument was based on
the work of DT Ross [1], and CM Geschke & JG Mitchell [2], who argued
that references ought to have intrinsically identical syntax, rather
than (as Parnas argued [3]) that they ought to get identical reference
syntax by being buried inside of procedures (and then you hope the
compiler will inline them).

Part of the argument I presented at the time was that array references
are really references to accessor procedures whose semantics are
specified in the standard and that the compiler knows how to write and
inline.  I also urged that arrays ought to be considered to be generic
accessors, so that one could have generic accessors of the same name, so
long as none of their specifics' argument lists consist of the same
number of integers as the rank of the array.

If you view X2 = F(1) as a function reference (and F(1) = 137 as an
updater reference), it's clear that the array F (which is really an
accessor procedure) and the function FI(I) in the generic F conflict.

That is, if we had started describing arrays as accessor procedures 22
years ago, the problem Kurt has brought to our attention today wouldn't
exist.

References:

[1] Douglas T. Ross "Uniform referents: An essential property for a
software engineering language," Software Engineering (J. T. Hon, Ed.)
vol 1, Academic Press (1969) pp 91-101.

[2] Charles M. Geschke and James G. Mitchell, "On the problem of uniform
references to data structures," IEEE TSE SE-1, 2 (June 1972) pp 207-219.

[3] David L. Parnas, "On the criteria to be used in decomposing systems
into modules," CACM 15, 12 (Dec 1972) pp 1053-1058.