Fortran - Statement function host association

Author

Statement function host association

John Harper

2005-05-13, 4:10 pm

F95 standard 14.6.1.3(i) says a function-name in a stmt-function-stmt
is inaccessible by that name by host association. Does that prohibit
programs like the following?

REAL sqr,xx
! sqr is a statement function used in an internal subprogram
sqr(xx) = xx**2
PRINT*,reabs(-6.0)
CONTAINS
REAL FUNCTION reabs(z)
REAL,INTENT(IN):: z
reabs = sqrt(sqr( z))
END FUNCTION reabs
END

If so, then all four f95 compilers I have access to allow it as a
language extension: g95 and NAG, Compaq, Sun f95. Some of them point
out, correctly, that statement functions are obsolescent.

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

Richard Maine

2005-05-13, 4:10 pm

harper@mcs.vuw.ac.nz (John Harper) writes:

> F95 standard 14.6.1.3(i) says a function-name in a stmt-function-stmt
> is inaccessible by that name by host association. Does that prohibit
> programs like the following?
>
> REAL sqr,xx
> ! sqr is a statement function used in an internal subprogram
> sqr(xx) = xx**2
> PRINT*,reabs(-6.0)
> CONTAINS
> REAL FUNCTION reabs(z)
> REAL,INTENT(IN):: z
> reabs = sqrt(sqr( z))
> END FUNCTION reabs
> END

No. That code is fine. You've misread the whole point of 14.6.1.3 (I'm
not meaning that in an insulting way; the section is a bit of a tangle
of standardese and is easy to get

).

That long list of things, which includes statement functions, is a
list of things that, if they appear in the *INNER* scoping unit, would
block host association of things by the same name. So this doesn't
mean that statement functions don't host associate; what it means is
that a statement function can block host association.

For example, the workings of 14.6.1.3 could be illustrated by the
following mofified version of your program.

REAL sqr,xx
external sqr !-- Assume one exists; I won't bother writing it.
print *, sqr(42.0) !-- This uses the external sqr
PRINT*,reabs(-6.0)
CONTAINS
REAL FUNCTION reabs(z)
REAL,INTENT(IN):: z
sqr(xx) = xx**2
!-- The statement function sqr in the line above "blocks"
!-- host association of the name sqr. So in this internal
!-- procedure, sqr is the name of the statement function
!-- instead of the external one.
reabs = sqrt(sqr( z))
END FUNCTION reabs
END

Because there is a statement function named sqr in the inner scoping
unit, anything of that same name in the host scoping unit is inaccessible
by host association. In this case, it is the external sqr that is not
host associated.

--
Richard Maine
email: my last name at domain
domain: summertriangle dot net

Herman D. Knoble

2005-05-13, 4:10 pm

This is an interesting example.
Making this a runable program (see below), it's interesting that
several compilers (latest versions) flag the statement function
sqr(xx) = xx**2 as invalid syntax.

In particular: Lahey(LF95), Intel(ifort), Compaq Visual(DF), all compile
this with no messages and the resulting code runs with expected results.

The compilers: Salford (ftn95), Pathscale(pathf90) Portland(pgf95) and
Absoft(f95) all flag the statement function as invalid syntax).

Skip Knoble

The code used was:

! By Richard Maine in response to John Harper posted 12 May 2005
! at comp.lang.fortran
!
! "For example, the workings of 14.6.1.3 could be illustrated by the
! following modified version of your program."

!"Because there is a statement function named sqr in the inner scoping
!unit, anything of that same name in the host scoping unit is
!inaccessible by host association. In this case, it is the external
! sqr that is not host associated."

Program SFunction

REAL :: sqr,xx
external sqr !-- Assume one exists
print *, sqr(42.0) !-- This uses the external sqr
PRINT*,reabs(-6.0)
CONTAINS
REAL FUNCTION reabs(z)
REAL,INTENT(IN):: z
sqr(xx) = xx**2
!-- The statement function sqr in the line above "blocks"
!-- host association of the name sqr. So in this internal
!-- procedure, sqr is the name of the statement function
!-- instead of the external one.

reabs = sqrt(sqr( z))
END FUNCTION reabs

end Program SFunction

function sqr(w) result(s)
real, Intent(in) :: w
real :: s
s = 2*w
end function sqr

On Wed, 11 May 2005 17:53:32 -0700, Richard Maine <nospam@see.signature> wrote:

-|harper@mcs.vuw.ac.nz (John Harper) writes:
-|
-|> F95 standard 14.6.1.3(i) says a function-name in a stmt-function-stmt
-|> is inaccessible by that name by host association. Does that prohibit
-|> programs like the following?
-|>
-|> REAL sqr,xx
-|> ! sqr is a statement function used in an internal subprogram
-|> sqr(xx) = xx**2
-|> PRINT*,reabs(-6.0)
-|> CONTAINS
-|> REAL FUNCTION reabs(z)
-|> REAL,INTENT(IN):: z
-|> reabs = sqrt(sqr( z))
-|> END FUNCTION reabs
-|> END
-|
-|No. That code is fine. You've misread the whole point of 14.6.1.3 (I'm
-|not meaning that in an insulting way; the section is a bit of a tangle
-|of standardese and is easy to get

James Giles

2005-05-13, 4:10 pm

Herman D. Knoble wrote:
> This is an interesting example.
> Making this a runable program (see below), it's interesting that
> several compilers (latest versions) flag the statement function
> sqr(xx) = xx**2 as invalid syntax.
>
> In particular: Lahey(LF95), Intel(ifort), Compaq Visual(DF), all
> compile
> this with no messages and the resulting code runs with expected
> results.
>
> The compilers: Salford (ftn95), Pathscale(pathf90) Portland(pgf95)
> and Absoft(f95) all flag the statement function as invalid syntax).
>
> Skip Knoble
....
> Program SFunction
>
> REAL :: sqr,xx
> external sqr !-- Assume one exists
....
> CONTAINS
> REAL FUNCTION reabs(z)
> REAL,INTENT(IN):: z
> sqr(xx) = xx**2

The syntactic form of a statement function definition is the
same as the syntactic form of an assignment statement. The
only way to tell the difference is to look up the "array name"
on the left of the assignment and see if it's declared in the
present context. Evidently, the compilers that work with
this example correctly treat the statement as a function
declaration if the name is not already declared as an
*array* and the non-array declaration is from host (or
possibly USE) association. The compilers that don't work
evidently assume that *any* visible declaration of the name
precludes it from being a statement function declarartion.

Consider the compiler's problem by comparing the above
example with:

Program SFunction

REAL :: sqr(50)
INTEGER :: xx
....
CONTAINS
REAL FUNCTION reabs(z)
REAL,INTENT(IN):: z
sqr(xx) = xx**2

This is really a fuzzy distinction. I'm not really sure that
I could point to specific language in the standard that clearly
requires the behavior I called correct in my first paragraph.

--
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

Richard E Maine

2005-05-13, 4:10 pm

On statement functions and host association.

In article
<_6Pge.206687$cg1.127314@bgtnsc04-news.ops.worldnet.att.net>,
"James Giles" <jamesgiles@worldnet.att.net> wrote:

....
> This is really a fuzzy distinction. I'm not really sure that
> I could point to specific language in the standard that clearly
> requires the behavior I called correct in my first paragraph.

Oh yeah. I am now reminded of a recent discussion of just this question
in J3. I had asked for an explanation of what I thought to be a quirky
requirement for statement functions. Well, actually quite a few of the
requirements for statement functions are quirky, but one of them in
particular had puzzled me. Even though this discussion was only a few
w

s ago, it had completely slipped my mind until I read Giles'
posting. (I basically never use statement functions these days; the only
reason I was looking at them was to be able to write about them
accurately; but having written the material in question, it appears to
have rapidly slipped back out of my mind).

The "strange" condition in question is the para after C1265 in f2003, at
[285:29-30] of the line-numbered 04-007 draft. I didn't bother to drag
out f95 to find the citation there, but I'm sure this is not new to
f2003.

"The declaration of a statement function with the same name as an
accessible entity from the host shall be preceded by the declaration of
its type in a type declaration statement."

As it was explained to me, the problem Giles points out is exactly why
this condition (or something related) is needed. The particular
condition is perhaps overkill in that most host associated things would
have caused no problem, but the restriction was phrased broadly instead
of targeting just the problem case.

In my opinion, this restriction makes the inclusion of statement
functions as one of the thing that block host association (in the
section that Ian asked about) sort of pointless. In order to be standard
conforming, the condition quoted above means that the host association
had to have already been blocked by the type declaration statement, so
saying that the statement function statement also blocks it seems sort
of pointless (and confusing) to me.

So my modification of Ian's example needs a REAL declaration in the
internal procedure in order to be standard conforming. Obviously, some
compilers accept it anyway, at least in the unambiguous cases. Now that
I'm reminded, I think I recall it being mentioned that some compilers
weren't quite as strict as the broad requirement of the standard. The
requirement is not a constraint, so compilers are not required to
diagnose it (though doing so would be helpful for those trying to write
to the standard).

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

robert.corbett@sun.com

2005-05-13, 4:10 pm

> This is really a fuzzy distinction. I'm not really sure that
> I could point to specific language in the standard that clearly
> requires the behavior I called correct in my first paragraph.

You are correct that the program is not standard compliant.
The requirement of the Fortran 95 standard that it violates is
given in Section 12.5.4.. It states

The definition of a statement function with the same name
as an accessible entity from the host shall be preceded by
the declaration of its type in a type declaration statement.

For the Fortran standard, this is a relatively clear statement.
The same requirement appears in the Fortran 2003 standard.

Bob Corbett

Herman D. Knoble

2005-05-13, 4:10 pm

Richard, Your Standards knowledge does it again:-)

Indeed when adding:

REAL sqr

to the internal procedure all the compilers I cited in my last post
compile the example and running the code works at run tome.

Skip

On Thu, 12 May 2005 14:25:30 -0700, Richard E Maine <nospam@see.signature> wrote:

-|So my modification of Ian's example needs a REAL declaration in the
-|internal procedure in order to be standard conforming.

John Harper

2005-05-16, 8:58 pm

In article <1115962211.357440.262380@z14g2000cwz.googlegroups.com>,
<robert.corbett@sun.com> wrote:
>
>You are correct that the program is not standard compliant.
>The requirement of the Fortran 95 standard that it violates is
>given in Section 12.5.4.. It states
>
> The definition of a statement function with the same name
> as an accessible entity from the host shall be preceded by
> the declaration of its type in a type declaration statement.

That part of Section 12.5.4 is in the text, not in a constraint.
Programmers beware, because that means that compilers are not obliged
to point out the violation.

By the way, this all arose because I wanted to declare and use a
function F in an internal subprogram, as the neatest way to write
a program (not the little test program you all saw!). That is, of
course, illegal in f95 and f2003 unless F is a statement function.

That seems to me to be a valid use of a statement function.
Has the time come to make statement functions non-obsolescent?

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

Richard E Maine

2005-05-16, 8:58 pm

In article <1116283311.942327@bats.mcs.vuw.ac.nz>,
harper@mcs.vuw.ac.nz (John Harper) wrote:

> By the way, this all arose because I wanted to declare and use a
> function F in an internal subprogram, as the neatest way to write
> a program (not the little test program you all saw!). That is, of
> course, illegal in f95 and f2003 unless F is a statement function.
>
> That seems to me to be a valid use of a statement function.
> Has the time come to make statement functions non-obsolescent?

Not in my personal opinion. Statement functions have all kinds of
quirks, some of which are pretty much unavoidable because of the fact
that there isn't anywhere "inside" of the statement function to declare
things. You won't find me supporting enhancements of statement functions
(including even making them non-obsolescent).

Sounds to me much more like an argument to allow internal procedures
inside of internal procedures. That's been proposed before and I know of
no huge reason why it won't work. In terms of the standard, it is
trivial. There might be some implementation complications with some
implementations in allowing arbitrarily deep nesting, but I'd be
surprised if there were any show-stoppers.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

John Harper

2005-05-17, 3:59 am

In article <nospam-C55A74.16021916052005@news.supernews.com>,
Richard E Maine <nospam@see.signature> wrote:
>
>Sounds to me much more like an argument to allow internal procedures
>inside of internal procedures. That's been proposed before and I know of
>no huge reason why it won't work.

I hope it happens then. After all Algol allowed it over 40 years ago.
It's one of the few ways in which Fortran still hasn't caught up.

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

Ron Shepard

2005-05-17, 3:59 am

In article <nospam-C55A74.16021916052005@news.supernews.com>,
Richard E Maine <nospam@see.signature> wrote:

> Sounds to me much more like an argument to allow internal procedures
> inside of internal procedures.

When this is done, there are two related problems that need to be
addressed. Currently there is no way to ensure that intended local
variables really are local. This is because "implicit none" does
not override host association, so the compiler cannot help you
achieve your goal by reporting all of the undeclared variables.
Second, there should be a simple way of excluding some or all host
association. These are problems with the current situation (a
single level of internal procedure), and this needs to be fixed in
any case, but the situation would get even worse with an arbitrary
number of internal procedure levels, all inheriting all of the
variables declared in the higher-level hosts.

$.02 -Ron Shepard

James Giles

2005-05-17, 3:59 am

Ron Shepard wrote:
> In article <nospam-C55A74.16021916052005@news.supernews.com>,
> Richard E Maine <nospam@see.signature> wrote:
>
>
> When this is done, there are two related problems that need to be
> addressed. Currently there is no way to ensure that intended local
> variables really are local. This is because "implicit none" does
> not override host association, so the compiler cannot help you
> achieve your goal by reporting all of the undeclared variables.
> Second, there should be a simple way of excluding some or all host
> association. These are problems with the current situation (a
> single level of internal procedure), and this needs to be fixed in
> any case, but the situation would get even worse with an arbitrary
> number of internal procedure levels, all inheriting all of the
> variables declared in the higher-level hosts.

I even made an official proposal for that. As far as I know the
committee was little interested. I heard second hand that there
was some interest in another part of the proposal that pertained
to USE association (that external procedures be allowed to USE
modules in which that procedure's interface was declared). But
the part of the proposal allowing internal procedures control
over host association was DOA.

In my own language, internal procedures inherit everything from
their host, but only if you use "fully qualified names". That is,
if the host's name is SUB1, and the internal procedure's name is
FUNC1, then X within SUB1 can be accessed as SUB1%X from
within FUNC1. If you want to reference X without qualification
inside FUNC1, you must explicitly import it from the host. Note
that in order to support INCLUDE files that contain the definitions
of internal procedures, there needs to be a generic name that is
always interpreted as the host's name (since the author of the
INCLUDE file can't know the name of the host that the procedures
will be included into). For that purpose, the name '_' always
means the immediate host. So, _%X is the name of the host's
X variable. Some other character might be a better choice. That's
why the language is still very experimental.

--
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

Dan Nagle

2005-05-17, 8:59 am

Hello,

Actually, the vote in Delft was to delete statement functions
in the 2008 standard.

--=20
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

On Mon, 16 May 2005 16:02:19 -0700, Richard E Maine
<nospam@see.signature> wrote:

>In article <1116283311.942327@bats.mcs.vuw.ac.nz>,
> harper@mcs.vuw.ac.nz (John Harper) wrote:
>
>
>Not in my personal opinion. Statement functions have all kinds of=20
>quirks, some of which are pretty much unavoidable because of the fact=20
>that there isn't anywhere "inside" of the statement function to declare=20
>things. You won't find me supporting enhancements of statement functions=
=20
>(including even making them non-obsolescent).
>
>Sounds to me much more like an argument to allow internal procedures=20
>inside of internal procedures. That's been proposed before and I know of=
=20
>no huge reason why it won't work. In terms of the standard, it is=20
>trivial. There might be some implementation complications with some=20
>implementations in allowing arbitrarily deep nesting, but I'd be=20
>surprised if there were any show-stoppers.

Jan Vorbrüggen

2005-05-17, 3:59 pm

> When this is done, there are two related problems that need to be
> addressed. Currently there is no way to ensure that intended local
> variables really are local. This is because "implicit none" does
> not override host association, so the compiler cannot help you
> achieve your goal by reporting all of the undeclared variables.
> Second, there should be a simple way of excluding some or all host
> association.

I used to think along similar lines...but then it came to me that this
is exactly the situation in occam2 (with arbitrarily deep nesting, BTW,
and exploited to considerable degree in real programs)...and I can't
remember that, in all those years, I had a single problem with importing
a variable name from an enclosing scope without intending to do so.
occam2 is, of course, different in some ways. The one problem of this
type I had, with F90, was that unintended aliasing between using the
name from the dummy argument list and the name of the corresponding
actual argument from the enclosing scope: but that problem cannot occur
in occam2 (because the scoping does not work across calls).

Jan

Paul Van Delst

2005-05-17, 3:59 pm

James Giles wrote:
> Ron Shepard wrote:
>
>
>
> I even made an official proposal for that. As far as I know the
> committee was little interested. I heard second hand that there
> was some interest in another part of the proposal that pertained
> to USE association (that external procedures be allowed to USE
> modules in which that procedure's interface was declared). But
> the part of the proposal allowing internal procedures control
> over host association was DOA.
>
> In my own language, internal procedures inherit everything from
> their host, but only if you use "fully qualified names". That is,
> if the host's name is SUB1, and the internal procedure's name is
> FUNC1, then X within SUB1 can be accessed as SUB1%X from
> within FUNC1. If you want to reference X without qualification
> inside FUNC1, you must explicitly import it from the host.

I like the idea of that. The instinct to *not* declare variables in Fortran (and assume
implict typing) is still pretty strong in some realtively new Fortran90/95 programmers.

I'm not sure about the syntax though. Would it be a doable thing to modify the IMPORT
statement in f2003 so it could be used in this sort of situation? E.g. (just so I'm sure
we're talking about the same sort of thing),

MODULE mymod
IMPLICIT NONE
INTEGER :: i
CONTAINS
SUBROUTINE sub1(x,y)
REAL, INTENT(IN) :: x(:)
REAL, INTENT(OUT) :: y(:)
DO i = 1, SIZE(x) ! <---- This would fail
...do some stuff...
END DO
END SUBROUTINE sub1
SUBROUTINE sub2(a,b)
REAL, INTENT(IN) :: a(:)
REAL, INTENT(OUT) :: b(:)
IMPORT :: i
DO i = 1, SIZE(a) ! <---- This would work
...do some stuff...
END DO
END SUBROUTINE sub2
END MODULE mymod

Of course, just writing the above made me think of several problems with this particular
use, e.g. being able to specify a default action at the module level -- like an EXPORT
statement where one could say
EXPORT [ALL]
or
EXPORT NONE
or
EXPORT [[::] export-name-list]
?
Or instead of EXPORT, maybe DISTRIBUTE? Or some nice, short verb that means "make
available"? :o)

I guess you'd then have to allow the same for IMPORT also at the subprogram level. My
module "preamble" would then get pretty busy what with
IMPLICIT NONE
EXPORT NONE
PRIVATE
just to establish the defaults I would prefer.

Oof. Anyway, I still like the idea of being able to control, beyond host association,
what module variables are "visible" to subprograms.

cheers,

paulv

p.s. After objecting to James Giles' suggested syntax, I'm amazed at the monstrosity I was
able to come up with in 5 minutes! I feel for the committee members. :o)

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

James Giles

2005-05-17, 8:58 pm

Jan Vorbrüggen wrote:
>
> I used to think along similar lines...but then it came to me that
> this is exactly the situation in occam2 (with arbitrarily deep
> nesting, BTW, and exploited to considerable degree in real
> programs)...and I can't remember that, in all those years, I had a
> single problem with importing a variable name from an enclosing
> scope without intending to do so. occam2 is, of course, different
> in some ways. [...]

Well, personal experience aside, there are others that have found
this to be a problem. I've seen the error in Fortran many times.
I've also seen the problem in Pascal (in supposedly professionally
written and verified code). Certain studies in the early 1970's
found sufficient problems to be concerned (W. A. Wolf, and M. Shaw,
"Global variable considered harmful", SIGPLAN Notices, vol. 8,
pp. 28-34, Feb. 1973). Wirth found it sufficiently troublesome that
Modula required explicit imports of host associated items. Etc.

The main problem with this kind of host association problem is
not its frequency but its invisibility. A program may run for its
entire "useful" life producing plausible wrong answers with this
kind of error in place - and no one is the wiser! And even when
some kind of problem is suspected, this is not the kind of cause
people look for (maybe it should be, but it isn't). So, programmers
come to people like me and say "I think the compiler is buggy, it's
producing wrong answers here..."

Fortran has some particularly messy instances possible (and I've
seen them reported). Such as:

Subroutine MySub(...)
... no use or declaration of any entity called J ...
Contains
Subroutine internal_1(...)
... no IMPLICIT NONE, but uses J as a misc. integer temp ...
... also calls INTERNAL_2 from time to time ...
...
Subroutine internal_2(...)
... no IMPLICIT NONE, but uses J as a misc. integer temp ...
...

Now, according to Fortran's rules, J behaves as-if it were declared
in the widest possible scope, MySub in this case. Which means that
the two internal procedures are actually sharing J!

I think the correct answer is to at least *allow* what many language
design researchers have been recommending for decades and give
programmers explicit control over host association.

--
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

James Giles

2005-05-17, 8:58 pm

Paul Van Delst wrote:
> James Giles wrote:
....
....[color=darkred]
> I'm not sure about the syntax though. Would it be a doable thing to
> modify the IMPORT statement in f2003 so it could be used in this
> sort of situation? E.g. (just so I'm sure we're talking about the
> same sort of thing),

[... example elided ...]

Yes, that's pretty much identical to on of the alternative forms
of my proposal that I actually suggested.

> Of course, just writing the above made me think of several problems
> with this particular use, e.g. being able to specify a default
> action at the module level -- like an EXPORT statement where one
> could say EXPORT [ALL]
> or
> EXPORT NONE
> or
> EXPORT [[::] export-name-list]
> ?
> Or instead of EXPORT, maybe DISTRIBUTE? Or some nice, short verb
> that means "make available"? :o)

Now I'm the one that's not sure of your intent. Do you mean that
the host can *force* host associated variables onto the unsuspecting
internal procedures using this syntax? Or do you mean that the host
can limit any internal procedures to using only those things that the
host permits using this syntax? The latter is an interesting idea, the
former I would fight against tooth and nail. If the latter though,
I really don't see the need. Does a host really need the ability to
hide names from it's internals? Considering that the internals will
only be using those things they explicit import anyway, and the
import list is presumably part of the documentation of the internal
procedure, the host *knows* what the procedures are using at all
times already.

--
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

2005-05-18, 4:01 am

Paul Van Delst wrote:
>
> I like the idea of that. The instinct to *not* declare variables in Fortran (and assume
> implict typing) is still pretty strong in some realtively new Fortran90/95 programmers.

No kidding, surely there must be some rational reason behind that. Even
on a dishwasher you don't go declaring anew every time a cup is added to
a tray...

> module "preamble" would then get pretty busy what with
> IMPLICIT NONE
> EXPORT NONE
> PRIVATE

A true peach - you need one more thing and you're done: SCRAP ALL

Michael Metcalf

2005-05-18, 8:57 am

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:bpuie.780623$w62.472457@bgtnsc05-news.ops.worldnet.att.net...
>
> Fortran has some particularly messy instances possible (and I've
> seen them reported). Such as:
>
> Subroutine MySub(...)
> ... no use or declaration of any entity called J ...
> Contains
> Subroutine internal_1(...)
> ... no IMPLICIT NONE, but uses J as a misc. integer temp ...
> ... also calls INTERNAL_2 from time to time ...
> ...
> Subroutine internal_2(...)
> ... no IMPLICIT NONE, but uses J as a misc. integer temp ...
> ...
>
> Now, according to Fortran's rules, J behaves as-if it were declared
> in the widest possible scope, MySub in this case. Which means that
> the two internal procedures are actually sharing J!
>
James, could you please construct a compilable example of this? As I
understand it, the 2 instances of J are separate local variables.

Regards,

Mike Metcalf

David Flower

2005-05-18, 8:57 am

Just how much legacy code is there around using statement functions ?

It is one thing to declare something obsolescent, quite another to make
it illegal.

Dan Nagle

2005-05-18, 8:57 am

Hello,

[I assume this is a response to my post, context is gone.]

On 18 May 2005 01:13:44 -0700, "David Flower" <DavJFlower@AOL.COM>
wrote:

>Just how much legacy code is there around using statement functions ?
>
>It is one thing to declare something obsolescent, quite another to make
>it illegal.

Well, "illegal", but still supported by all compilers.

--=20
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

Jan Vorbrüggen

2005-05-18, 8:57 am

> Fortran has some particularly messy instances possible (and I've
> seen them reported). Such as:
>
> Subroutine MySub(...)
> ... no use or declaration of any entity called J ...
> Contains
> Subroutine internal_1(...)
> ... no IMPLICIT NONE, but uses J as a misc. integer temp ...
> ... also calls INTERNAL_2 from time to time ...
> ...
> Subroutine internal_2(...)
> ... no IMPLICIT NONE, but uses J as a misc. integer temp ...
> ...
>
> Now, according to Fortran's rules, J behaves as-if it were declared
> in the widest possible scope, MySub in this case. Which means that
> the two internal procedures are actually sharing J!

If that is indeed the case, I consider this broken language design.
No other language I know of does that. It certainly would have broken
some of our occam2 code, would that language have similar rules.

> I think the correct answer is to at least *allow* what many language
> design researchers have been recommending for decades and give
> programmers explicit control over host association.

That I can definitely agree with. It is always a good idea to offer
control.

Jan

Paul Van Delst

2005-05-18, 4:00 pm

James Giles wrote:
> Paul Van Delst wrote:
>
>
> ...
>
>
> ...
>
>
>
> [... example elided ...]
>
> Yes, that's pretty much identical to on of the alternative forms
> of my proposal that I actually suggested.
>
>
>
>
> Now I'm the one that's not sure of your intent. Do you mean that
> the host can *force* host associated variables onto the unsuspecting
> internal procedures using this syntax?

No.

> Or do you mean that the host
> can limit any internal procedures to using only those things that the
> host permits using this syntax?

Yes.

I was really just thinking of how one could specify the opposite of the default action
(e.g. like implicit none).

> The latter is an interesting idea, the
> former I would fight against tooth and nail. If the latter though,
> I really don't see the need. Does a host really need the ability to
> hide names from it's internals? Considering that the internals will
> only be using those things they explicit import anyway, and the
> import list is presumably part of the documentation of the internal
> procedure, the host *knows* what the procedures are using at all
> times already.

Well now you're just exposing the lack of thought I put into my post! :o) It was one of
those "make it up as you go along" things so not a lot of thought was put into it. I wrote
down an example where I thought it may be needed, but when I did I saw that it didn't
really make a lot of sense. So, yes, there doesn't appear to be any need for an
EXPORT-type of statement like the one I suggested.

I still like the idea of a "modified" IMPORT, or even something syntax-y along the lines
of James Giles' suggestion.

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

Richard E Maine

2005-05-18, 4:00 pm

In article
<bpuie.780623$w62.472457@bgtnsc05-news.ops.worldnet.att.net>,
"James Giles" <jamesgiles@worldnet.att.net> wrote:

> Fortran has some particularly messy instances possible (and I've
> seen them reported). Such as:
>
> Subroutine MySub(...)
> ... no use or declaration of any entity called J ...
> Contains
> Subroutine internal_1(...)
> ... no IMPLICIT NONE, but uses J as a misc. integer temp ...
> ... also calls INTERNAL_2 from time to time ...
> ...
> Subroutine internal_2(...)
> ... no IMPLICIT NONE, but uses J as a misc. integer temp ...
> ...
>
> Now, according to Fortran's rules, J behaves as-if it were declared
> in the widest possible scope, MySub in this case. Which means that
> the two internal procedures are actually sharing J!

I'm afraid that I don't believe that. I'm not sure what rules you think
would imply that, but I sure can't see any such implication anywhere.
The 3 compilers I just tried all agree with me. Given the program

program giles
call internal_1
call internal_2
contains
subroutine internal_1
j = 7
call internal_2
write (*,*) j
end subroutine internal_1
subroutine internal_2
j = 42
write (*,*) j
end subroutine internal_2
end program giles

all 3 compilers (nag, g95, gfortran) gave me the expected outputs
(42,7,42).

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

David Flower

2005-05-18, 4:00 pm

The problem with making anything 'illegal' is that some twit will
introduce a new feature that forces a compiler to reject the previous
interpretation.

Then it cannot be 'supported by all compilers'

Dick Hendrickson

2005-05-18, 4:00 pm

David Flower wrote:
> The problem with making anything 'illegal' is that some twit will
> introduce a new feature that forces a compiler to reject the previous
> interpretation.
That's improbable. In round numbers, half of J3 are
vendors. They'll have to support statement functions for
a long time and are very unlikely to support anything
that will be backwards incompatible. Heck, there's not
even anything that's incompatible with Hollerith. (Although
REAL*4 HENRY
can be a bugger to parse.)

Dick Hendrickson
>
> Then it cannot be 'supported by all compilers'
>

James Giles

2005-05-18, 8:58 pm

Michael Metcalf wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:bpuie.780623$w62.472457@bgtnsc05-news.ops.worldnet.att.net...
....
> James, could you please construct a compilable example of this? As I
> understand it, the 2 instances of J are separate local variables.

Well, now I find I need an interp. The statement is (quoted from page 93
of the f2003 standard, since that's most easily available at the moment,
about line 13):

The data entity is treated as if it were declared in an explicit type
declaration in the outermost scoping unit in which it appears.

Now to me that means that the two J's ought to be shared, but the
standard then gives a (non-normative) example showing a similar
case in which the variables (Z in that case) are not shared.

--
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

James Giles

2005-05-18, 8:58 pm

Dan Nagle wrote:
> Hello,
>
> Actually, the vote in Delft was to delete statement functions
> in the 2008 standard.

If I were on the committee, I'd vote to retain statement functions.
I find that Rich Maine's complaint about them (that you can't
make declarations within them) is their main advantage. If
all I want is a shorthand way of writing a frequently repeated
expression, having to write it as a verbose multiline block
of code with lots of declarations actually removes any advantage.

There are some existing problems with statement functions
(which I don't think the committee will ever fix). Most have
been addressed in this thread. One being that it's difficult
to tell the difference between a statement function declaration
and an assignment in cases where host association is occuring.
The standard "solves" this problem by requiring a type declaration
of the statement function's name.

The problem with that is I would prefer that statement functions
be inherently generic. That is, the return type of the statement
function should be the result type (rank, KIND) of the expression
that defines it based on the types (ranks, KINDs) of the actual
arguments to the function.

--
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

Duane Bozarth

2005-05-18, 8:58 pm

James Giles wrote:
>
> Michael Metcalf wrote:
> ...
>
> Well, now I find I need an interp. The statement is (quoted from page 93
> of the f2003 standard, since that's most easily available at the moment,
> about line 13):
>
> The data entity is treated as if it were declared in an explicit type
> declaration in the outermost scoping unit in which it appears.
>
> Now to me that means that the two J's ought to be shared, but the
> standard then gives a (non-normative) example showing a similar
> case in which the variables (Z in that case) are not shared.
>
> --
> J. Giles

But in this case aren't the two relevant scoping units the subroutines
in which the two instances of the (local to each) instances of J are
defined? That's certainly my interpretation.

glen herrmannsfeldt

2005-05-18, 8:58 pm

James Giles wrote:
(snip)

> The problem with that is I would prefer that statement functions
> be inherently generic. That is, the return type of the statement
> function should be the result type (rank, KIND) of the expression
> that defines it based on the types (ranks, KINDs) of the actual
> arguments to the function.

Maybe like C preprocessor macros?

Though statement functions have a small advantage in that the precedence
rules still apply. C macros should have parenthesis around argument
references, and around the whole replacement to guard against surprises.

#define add(a,b) a+b

c=c*add(x,y);

expands to

c=c*x+y;

Somewhat unfunction like.

-- glen

James Giles

2005-05-18, 8:58 pm

glen herrmannsfeldt wrote:
> James Giles wrote:
> (snip)
>
>
> Maybe like C preprocessor macros?
>
> Though statement functions have a small advantage in that the
> precedence rules still apply. C macros should have parenthesis
> around argument references, and around the whole replacement to
> guard against surprises.

But, you still have the surprise that arguments that have side-effects
may have those evaluated twice:

macro double(x) = ((x)+(x))

later called with

z = double(f(a)) ! f is a function with side-effects

No, I don't like macros for this purpose at all. Even without
the side-effect argument, the extra parenthesis are easy to forget
and make the code unnecessarily harder to read.

--
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

James Giles

2005-05-18, 8:58 pm

Duane Bozarth wrote:
> James Giles wrote:
....
....[color=darkred]
> But in this case aren't the two relevant scoping units the
> subroutines in which the two instances of the (local to each)
> instances of J are defined? That's certainly my interpretation.

Then why the word "outermost" in the standard document? If
the implicit declaration is to correspond to a virtual explicit
declaraction in the *same* scope as the implicit variable is used,
why not say so?

--
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

Duane Bozarth

2005-05-18, 8:58 pm

James Giles wrote:
>
> Duane Bozarth wrote:
> ...
> ...
>
> Then why the word "outermost" in the standard document? If
> the implicit declaration is to correspond to a virtual explicit
> declaraction in the *same* scope as the implicit variable is used,
> why not say so?

Can't answer that specifically...Richard probably can at least
conjecture.

James Giles

2005-05-18, 8:58 pm

Duane Bozarth wrote:
> James Giles wrote:
....
>
> Can't answer that specifically...Richard probably can at least
> conjecture.

Well, anyone can conjecture. I find that the same wording is in
the F90 document which predates Rich's connection with the
committee. I suspect the reasons for that phrasing might be
lost completely. Even the person that wrote it probably no
longer remembers doing so, much less why it was phrased
as it was.

--
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

Duane Bozarth

2005-05-18, 8:58 pm

James Giles wrote:
>
> Duane Bozarth wrote:
> ...
>
> Well, anyone can conjecture. I find that the same wording is in
> the F90 document which predates Rich's connection with the
> committee. I suspect the reasons for that phrasing might be
> lost completely. Even the person that wrote it probably no
> longer remembers doing so, much less why it was phrased
> as it was.
>

Well, true...inadvertent word choice, no doubt. "Reasoned conjecture"
based on participation wherein remanants of having heard/participated in
discussions would allow for an "educated" opinion, perhaps? Actually,
my conjecture was that as current editor he tends to think about such
wordings and there just might be a good chance he's actually thought
about this one before. :)

James Van Buskirk

2005-05-18, 8:58 pm

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:bdNie.786138$w62.36908@bgtnsc05-news.ops.worldnet.att.net...

> Then why the word "outermost" in the standard document? If
> the implicit declaration is to correspond to a virtual explicit
> declaraction in the *same* scope as the implicit variable is used,
> why not say so?

I look at this in the context of ISO/IEC 1539-1:1997(E),
section 2.2:

"A program unit consists of a set of nonoverlapping scoping
units. A scoping unit is
....
(3) A program unit or subprogram, excluding derived-type
definitions, procedure interface bodies, and subprograms
in it."

Given the above definition I find it difficult to come
to the conclusion that the two J's in your example lie in
the same scoping unit.

If you were to say that the standards treatment of implicitly
typed variables (including result variables) is perhaps
incomplete of even inconsistent, I would have to be in full
agreement. It is only on this isolated issue that my views
differ.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

James Giles

2005-05-18, 8:58 pm

James Van Buskirk wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:bdNie.786138$w62.36908@bgtnsc05-news.ops.worldnet.att.net...
>
>
> I look at this in the context of ISO/IEC 1539-1:1997(E),
> section 2.2:
>
> "A program unit consists of a set of nonoverlapping scoping
> units. A scoping unit is
> ...
> (3) A program unit or subprogram, excluding derived-type
> definitions, procedure interface bodies, and subprograms
> in it."
>
> Given the above definition I find it difficult to come
> to the conclusion that the two J's in your example lie in
> the same scoping unit.

Given that definition, I find it difficult to even understand
the meaning of the word "outermost" in the description of
how implicit variables are handled. I was assuming that
the word "outermost" had its most natural meaning in the
context of the discussion - and that suggests that the two
J's in my example are both treated as if they were explicitly
declared in the parent scope. If that's not the case, the
word "outermost" should certainly be deleted since it's
not just unnecessary, but contrary to the intent.

--
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

James Van Buskirk

2005-05-18, 8:58 pm

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:zbPie.227020$cg1.6971@bgtnsc04-news.ops.worldnet.att.net...

> Given that definition, I find it difficult to even understand
> the meaning of the word "outermost" in the description of
> how implicit variables are handled. I was assuming that
> the word "outermost" had its most natural meaning in the
> context of the discussion - and that suggests that the two
> J's in my example are both treated as if they were explicitly
> declared in the parent scope. If that's not the case, the
> word "outermost" should certainly be deleted since it's
> not just unnecessary, but contrary to the intent.

Just running out the door, so I am not taking time to check
the standard, but I think that such things as ac-do-variables
or the index-name of a forall construct have a more local
scope and the passage you have been quoting is simply trying
to say that even though the scope of such a variable is
restriced, it implies a declaration valid in the scoping
unit that contains the array constructor or forall construct.
To see what I mean, try modifying your example with an array
constructor or forall that uses an implicitly declared J as
described above. I betcha the J's in the internal subroutines
in, I believe it was Richard's, compilable example in this
thread would now overlap.

Another tricky thing with implicitly typed variables is when
they are used in specification statements, especially implicit
statements, and nowhere else in the scoping unit.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Richard E Maine

2005-05-18, 8:58 pm

In article
<abMie.785818$w62.126265@bgtnsc05-news.ops.worldnet.att.net>,
"James Giles" <jamesgiles@worldnet.att.net> wrote:

> The data entity is treated as if it were declared in an explicit type
> declaration in the outermost scoping unit in which it appears.
>
> Now to me that means that the two J's ought to be shared, but the
> standard then gives a (non-normative) example showing a similar
> case in which the variables (Z in that case) are not shared.

The data entity in question doesn't appear in the host scoping unit. The
above doesn't say anything about extrapolating to the highest common
point or anything like that. It says "appears", which I take to be quite
literally intended.

I don't think an interp is needed here. The standard says "appears" and
means exactly that. Of course, my opinion isn't the "rule".

And I'd say that you have 2 separate data entities here anyway.

As I said, all the compilers I tried agree with me.

And my carpool just left after bugging me, so I better hurry off or I'll
be here all night. :-( The hastiness might show above; if so. sorry.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

James Giles

2005-05-18, 8:58 pm

James Van Buskirk wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:zbPie.227020$cg1.6971@bgtnsc04-news.ops.worldnet.att.net...
>
>
> Just running out the door, so I am not taking time to check
> the standard, but I think that such things as ac-do-variables
> or the index-name of a forall construct have a more local
> scope and the passage you have been quoting is simply trying
> to say that even though the scope of such a variable is
> restriced, it implies a declaration valid in the scoping
> unit that contains the array constructor or forall construct.

None of those places are scoping units. By your own quoted
passage (looking at the rest of §2.2 of the F95 doc), a scoping
unit is:

(1) A derived-type definition (4.4.1),
(2) A procedure interface body, excluding any derived-type
definitions and procedure interface bodies in it (12.3.2.1), or
(3) A program unit or subprogram, excluding derived-type
definitions, procedure interface bodies, and subprograms in it.

The problem is one of ordinary English usage. In _Alice in
Wonderland_, the title character is invited to take some more
tea. She inquires how she can take more when she had not
yet had any. The reply is that she certainly cannot take less!
But, Alice was right. In English, an adjective is not used to
distinguish cases that need no distinguishing. You don't talk
about *more* tea unless there has already been some. You
don't talk about the *last* door on the right if there's only
one on the right to choose from. ... And you don't talk about
the *outermost* scoping unit if there's only one to choose from.
The existence of such an adjective implies that there are cases
to choose from. In the case in question, I made the obvious
inferrence.

I don't know why my position is the one being critiqued here.
I am already on record as preferring the interpretation everyone
agrees is the correct one. The fact that, linguistically, the present
normative part of the standard suggests (at least) some other
interpretation is not my fault.

P.S.

I *WISH* implied do variables and FORALL index-names were
in a separate scope! They are in my preprocessed language (though
both have a different syntax there). It would simplify their use
considerably.

--
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

James Giles

2005-05-18, 8:58 pm

Richard E Maine wrote:
....
> The data entity in question doesn't appear in the host scoping
> unit. The above doesn't say anything about extrapolating to the
> highest common point or anything like that. It says "appears",
> which I take to be quite literally intended.

Well, based on the careful examination of other requirements
of the standard, an implicitly declared entity only *can* appear
in a single scoping unit. That still means that the choice implied
by the use of the word "outermost" is, at best, misleading. The
fact remains that whatever that phase actually means (and in
conventional English it means something different than everyone
agrees is to be preferred) is the actual rule of Fortran - the
phrase is normative, the examples are not.

(I've suggested in the past that the decision to declare examples
to be non-normative was a mistake.)

--
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

Richard Maine

2005-05-19, 4:00 am

[Home now, with a little more time to compose something - not that I
feel like spedning a real long time on this at home right now, but
longer than when I was rushing out the door at work.]

"James Giles" <jamesgiles@worldnet.att.net> writes:

> Given that definition, I find it difficult to even understand
> the meaning of the word "outermost" in the description of
> how implicit variables are handled. I was assuming that
> the word "outermost" had its most natural meaning in the
> context of the discussion - and that suggests that the two
> J's in my example are both treated as if they were explicitly
> declared in the parent scope. If that's not the case, the
> word "outermost" should certainly be deleted since it's
> not just unnecessary, but contrary to the intent.

I won't try to defend the perfection of the wording choices in the
standard. That would be a hopeless task, and one handicapped by the
fact that I think the wording choices are pretty bad in some areas.
So I'll not get into whether "outermost" is quite the right word here.

But I will note that I think you are looking in the wrong place for
conclusions about what variables are "shared". Your quote is from the
section on implicit typing. It does allude to multiple scoping units
because that can make a difference in implicit typing (see below).
But this isn't the place to look to find out how host association
works and thus which variables are "shared". For that, look in the
host association section. The host association section is where you
will find out whether the 2 internal procedures share a variable or
not (and in short, the answer is "yes" if it is also in their common
host, but "no" otherwise).

What the cited material is about is this. Given (from the rules
elsewhere on host association) that you have an implicitly typed
variable "shared" by host association, which scoping unit does it get
its implicit typing from (since the implicit typing rules can be
different in different scoping units)? The answer is the "outermost",
"highest level", or whatever term is best. (And there always will be
a unique highest level one).

--
Richard Maine
email: my last name at domain
domain: summertriangle dot net

James Giles

2005-05-19, 4:00 am

Richard Maine wrote:
....
> What the cited material is about is this. Given (from the rules
> elsewhere on host association) that you have an implicitly typed
> variable "shared" by host association, which scoping unit does it
> get its implicit typing from (since the implicit typing rules can be
> different in different scoping units)? The answer is the
> "outermost", "highest level", or whatever term is best. (And there
> always will be a unique highest level one).

The answer is not the "outermost" or the "highest level". It turns
out that the answer is *always* the "most local", "innermost", or
whatever term is best. No, that's not true either. It turns out that
there are no choices at all - there is only *one* possible scope to
choose from (as per the discussion with, and references cited by,
JvB). There should be no adjective used in describing the scoping
unit at all.

(There are only two places in the whole standard where terms
like "outer scope", etc., are even plausibly usable: both involve
CONTAINS. The two places are internal procedures and module
procedures. In both cases, "outer scope" might be read to mean
"host scope". There is no other sensible place to apply such terms
in the whole language. No other things described as "scoping units"
may be considered nested in any way at all. And, officially, those
are separate scopes too.)

--
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

James Giles

2005-05-19, 4:00 am

Richard Maine wrote:
.....
> I am perhaps recklessly confident that every compiler you try this
> on will interpret it the same way as I did. So if you think that
> the standard means something different, you'll have a lot of vendors
> to convince otherwise.

I agree. I've said many times *emphatically* that the way you're
describing is in fact the way it should work. Why you are continuing
to argue as if I said otherwise is beyond my comprehension.

> If you are just arguing that the standard doesn't say it correctly,
> then I'll drop the whole thing. Maybe you are right; that's not
> something I'm interested in debating at the moment.

The standard most emphatically says it dead wrong. That's the
problem. It turns out that there is, in English, no legitimate way
to use the word "outermost" in the sentence describing how
implicit varaibles are treated. No use of an implicit variable
can occur inside more than one scoping unit and all such uses
occur inside at leat one scoping unit. There are no choices to
make. The effort to make sense of the standard document (in
what is, after all, a normative phrase) leads to the obvious
conclusion that it must be referring to host association. Well,
it turns out that it almost certainly isn't.

That means it's just plain wrong. Wrong use of English. It
really is wrong. Sure, you could say that the *only* scoping
unit is the outermost, but it's also the innermost, the greenest,
the hotest, the most aggressive, and the least pretty. All of them
irrelevant, and all of them inappropriate uses of English when
there is never a choice in the first place.

--
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

glen herrmannsfeldt

2005-05-19, 4:00 am

James Giles wrote:
> glen herrmannsfeldt wrote:
[color=darkred]
(snip)
[color=darkred]
[color=darkred]
[color=darkred]
> But, you still have the surprise that arguments that have
> side-effects may have those evaluated twice:

(snip)

> No, I don't like macros for this purpose at all. Even without
> the side-effect argument, the extra parenthesis are easy to forget
> and make the code unnecessarily harder to read.

Yes, so have something where all the usual precedence rules apply,
but the expression is evaluated with whatever type the arguments have.

Well, there are stories about the IBM Fortran H compiler evaluating
statement functions inline (*), but I don't know that all compilers
do that. If you do, it would seem easy to make them type generic
in the way that C macros are without the other problems.

(*) There was a story once about a Fortran benchmark program with
lots of complicated expressions all coded using statement functions.
It turned out that the Fortran H compiler inlined statement functions
and then did constant expression evaluation, doing the entire
calculation at compile time. The result, of course, ran very fast.
Other than that, I don't know which compilers inline them.

-- glen

Jan Vorbrüggen

2005-05-19, 8:56 am

> Well, based on the careful examination of other requirements
> of the standard, an implicitly declared entity only *can* appear
> in a single scoping unit.

That I don't understand. Let me explain why.

I take the word "appears" to mean "the appropriate letters spelling out
the entity name appear in the source code".

As I understand the definition of scoping units from the material cited
in this thread, the host and the contained subroutine are two seperate
scopes, with the latter contained within the former, from which the meaning
of "outermost" etc. can be derived.

The wording in question appears in the section on how implicit typing
should work.

If the same entity name appears in both the host scope and any contained
scope, host association rules say they are the same entity. As an aside,
this means that by transitivity, if there are two contained scopes using
an entity with the same name and you now add that name in the host scope,
the two previously seperate entities become one, the one located in the
host scope.

Given this, the language in the standard that triggered this discussion
basically says that for an implicitly typed entity, its type is derived
from whatever implicit typing rules where in effect in the outermost scope
in which it appears. This outermost scope can be the only scope if the
entity only appears in the contained subroutine. If it _does_ appear in
in both the host and the contained scope, then the rules in effect in
the host scope apply, not whatever might be in force in the contained
scope.

I believe that was the point Richard was trying to make in his example,
by introducing the IMPLICIT CHARACTER(J) in the contained subroutine.

It might appear that this is stating the obvious. In Richard's example,
one could change the language of the standard to say that the rules of
the first scope in which the entity appears are to be applied. If the
ordering rules allowed any _host_ executable statements to appear after
the CONTAINS statement, then an entity could be first referenced - and
thus implicitly declared - in the host scope _after_ being referenced
in one of the contained scopes. From the CVF documentation, however, it
appears that this is not allowed, so the wordings "outermost scope in
which it appears" and "first scope in which it appears" are equivalent.
I do think that the "outermost" conveys the intent better.

Jan

James Van Buskirk

2005-05-19, 8:56 am

"Richard Maine" <nospam@see.signature> wrote in message
news:87k6lwj7sq.fsf@vega.site...

> I haven't bothered to try it. But that's partly because I am
> unreasonably confident that I know what it will do (possible typos
> excepted). And don't have a Fortran compiler handy on this machine
> anyway - suppose I ought to download a copy of g95 to fix that.

Here is my version of this compiler torture test:

program shared_implicit
real x(3)

x = (/(j,j=1,3)/)
call inner_1
contains
subroutine inner_1
implicit real(j)
j = transfer(42,j)
write(*,*) j
call inner_2
write(*,*) j
end subroutine inner_1
subroutine inner_2
implicit character(j)
j = transfer(17,j)
write(*,*) j
end subroutine inner_2
end program shared_implicit

Results: lf95 as expected, cvf prints out:

5.8854536E-44
?
5.8854536E-44

and g95 refuses to compile. I didn't try on a recent version
of g95, though.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

James Giles

2005-05-19, 8:56 am

Jan Vorbrüggen wrote:
>
> That I don't understand. Let me explain why.
>
> I take the word "appears" to mean "the appropriate letters spelling
> out the entity name appear in the source code".
>
> As I understand the definition of scoping units from the material
> cited in this thread, the host and the contained subroutine are two
> seperate scopes, with the latter contained within the former, from
> which the meaning of "outermost" etc. can be derived.

The problem is that particular meaning of "outermost" is most
emphatically *not* the one anyone thinks is intended. Though,
I still maintain that no other meaning of "outermost" is sensible
either...

> If the same entity name appears in both the host scope and any
> contained scope, host association rules say they are the same
> entity. [...]

In which case, the name is *not* implicitly declared in the
contained scope, it's inherited by host association there.
The only place a name can be implicitly delcared is in the
local scope where it is used without explicit declaration and
without host association.

--
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

Dan Nagle

2005-05-19, 8:56 am

Hello,

On Wed, 18 May 2005 19:11:04 GMT, "James Giles"
<jamesgiles@worldnet.att.net> wrote:

>Dan Nagle wrote:
>
>If I were on the committee, I'd vote to retain statement functions.

<snip>

One advantage of removing statement functions from the standard
is that is simplifies the standard, thereby allowing language issues
to be addressed more directly. How many times does the standard
have to say 'except statement functions which are a little different'.
Specifically, scope of variable names is made more complex
due to special casing for statement functions.

Given the WG5 resolutions, which are J3's marching orders at least
until February 2006, some effort is likely to be spent
clarifying language ('CCR'). Please see WG5 document N1636
for the whole resolutions of the Delft meeting.
http://www.nag.co.uk/sc22wg5

All of this, of course, doesn't remove in any way, statement functions
from compilers. Multi-million hardware decisions can rest
on which compiler will compile a legacy application.

--=20
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

John Harper

2005-05-20, 4:00 am

In article <d6esmg$poe$02$1@news.t-online.com>,
Michael Metcalf <metcalfmetcalf@compuserve.com> wrote:
>
>"James Giles" <jamesgiles@worldnet.att.net> wrote in message
>news:bpuie.780623$w62.472457@bgtnsc05-news.ops.worldnet.att.net...
>James, could you please construct a compilable example of this? As I
>understand it, the 2 instances of J are separate local variables.

I don't see an example from James, but here is my own effort, in which
j appears explicitly in the outermost scope but i does not.

PROGRAM outer
j = 666
CALL inner1
CALL inner2
CONTAINS
SUBROUTINE inner1
i = 1
j = 1
CALL inner2
END SUBROUTINE inner1
SUBROUTINE inner2
i = i + 1
j = j + 1
PRINT "(2I4)",i,j
END SUBROUTINE inner2
END PROGRAM outer

G95 compiles that with no messages, and prints
1 2
1 3
Sun and Compaq f95 both compile with no messages, and print
1 2
2 3
NAG f95 says at compile time
cc: Warning: testhost.f90, line 12: The scalar variable "i_" is fetched
but not initialized. (uninit1)
i_ = i_ + 1;
-----^
and at run time it prints
1 2
1 3

I shall be interested to hear whether my program violates the f95
standard. If it does not, it seems to me that either the standard is
ambiguous or two of those compilers are violating it (but which two?)

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

Ken Fairfield

2005-05-20, 4:00 am

John Harper wrote:
> In article <d6esmg$poe$02$1@news.t-online.com>,
> Michael Metcalf <metcalfmetcalf@compuserve.com> wrote:
>
>
>
> I don't see an example from James, but here is my own effort, in which
> j appears explicitly in the outermost scope but i does not.
>
> PROGRAM outer
> j = 666
> CALL inner1
> CALL inner2
> CONTAINS
> SUBROUTINE inner1
> i = 1
> j = 1
> CALL inner2
> END SUBROUTINE inner1
> SUBROUTINE inner2
> i = i + 1
> j = j + 1
> PRINT "(2I4)",i,j
> END SUBROUTINE inner2
> END PROGRAM outer
>
> G95 compiles that with no messages, and prints
> 1 2
> 1 3
> Sun and Compaq f95 both compile with no messages, and print
> 1 2
> 2 3
> NAG f95 says at compile time
> cc: Warning: testhost.f90, line 12: The scalar variable "i_" is fetched
> but not initialized. (uninit1)
> i_ = i_ + 1;
> -----^
> and at run time it prints
> 1 2
> 1 3
>
> I shall be interested to hear whether my program violates the f95
> standard. If it does not, it seems to me that either the standard is
> ambiguous or two of those compilers are violating it (but which two?)

Good example. :-) Given the previous disussion in this thread,
since "i" is not host associated, the "i" in inner1 is (or should
be) different from the "i" in inner2. It looks like NAG f95 got
this right and correctly flags the "i = i + 1" in inner2 since
i was never initialized. All of G95, Sun and Compaq f95 fail to
detect the program error (but then, since it's a non-conforming
program, they can print anything).

Regards, Ken
--
I don't speak for Intel, Intel doesn't speak for me...

Ken Fairfield
D1C Automation VMS System Support
who: kenneth dot h dot fairfield
where: intel dot com

James Giles

2005-05-20, 4:00 am

John Harper wrote:
.....
> I don't see an example from James, but here is my own effort, in
> which j appears explicitly in the outermost scope but i does not.
>
> PROGRAM outer
> j = 666
> CALL inner1
> CALL inner2
> CONTAINS
> SUBROUTINE inner1
> i = 1
> j = 1
> CALL inner2
> END SUBROUTINE inner1
> SUBROUTINE inner2
> i = i + 1
> j = j + 1
> PRINT "(2I4)",i,j
> END SUBROUTINE inner2
> END PROGRAM outer
>
> G95 compiles that with no messages, and prints
> 1 2
> 1 3

The program is not standard conforming for the reason given by
your NAG compiler: INNER2 references I before any value is
assigned. G95 evidently initializes with zero and doesn't detect
(or, at least, doesn't report) the violation.

> Sun and Compaq f95 both compile with no messages, and print
> 1 2
> 2 3

Sun and Compaq evidently initialize with zero *and* make the
variables SAVEd by default.

> NAG f95 says at compile time
> cc: Warning: testhost.f90, line 12: The scalar variable "i_" is
> fetched but not initialized. (uninit1)
> i_ = i_ + 1;
> -----^

A correct warning. Though "decorating" the identifier with an
underscore in the messages is kind of obnoxious.

> and at run time it prints
> 1 2
> 1 3

With the same conclusion as the G95 case: non-SAVEd but zero
initialized.

The concensus is that my interpretation of the standard's phrasing
(which I still maintain is the only reasonable way to read the actual
normative requirement) is actually not the intent of the document
and that implementations *should* behave as I would prefer: in
your example that means that I is not the same entity in the two
INNER procedures. There is, peculiarly, strong resistence to
deleting the word "outermost" in the disputed phrase, even though
that would make the preferred interpretation obvious.

--
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

robert.corbett@sun.com

2005-05-21, 3:58 am

> Heck, there's not even anything that's incompatible with
> Hollerith. (Although
>
> REAL*4 HENRY
>
> can be a bugger to parse.)

There is nothing hard about it. In most Fortran compilers, the
lexical analyzer handles it. If the compiler see a sequence of
letters followed by an asterisk which is in turn followed by a
digit, it knows that the digit must be the start of an integer, not
a Hollerith constant. Unlike cases such as IF and DO
statements, the lexical analyzer does not need to do any
lookahead to handle such a statement.

Bob Corbett

Steve Lionel

2005-05-31, 4:01 pm

On Wed, 19 May 2005 , "James Van Buskirk" <not_valid@comcast.net> wrote:

> Here is my version of this compiler torture test:
>
> program shared_implicit
> real x(3)
>
> x = (/(j,j=1,3)/)
> call inner_1
> contains
> subroutine inner_1
> implicit real(j)
> j = transfer(42,j)
> write(*,*) j
> call inner_2
> write(*,*) j
> end subroutine inner_1
> subroutine inner_2
> implicit character(j)
> j = transfer(17,j)
> write(*,*) j
> end subroutine inner_2
> end program shared_implicit
>
> Results: lf95 as expected, cvf prints out:
>
> 5.8854536E-44
> ?
> 5.8854536E-44
>
> and g95 refuses to compile. I didn't try on a recent version
> of g95, though.

This was part of a discussion regarding the scope of implied-DO variables.
(My news server has dropped the original article, so my position in the thread
for this reply is not correct..)

I sent James e-mail asking him what lf95 produced that he "expected", and he
replied with an elaboration as to why he thought this was correc t. I
responded to him on this, and James asked that I post the response to the
group. My response follows.

--

I'm astonished that none of the standards committee members pointed out that
this was the subject of the very first interpretation to F95 and was included
in Corrigendum 1.

The interpretation text is as follows:

NUMBER: 000001
TITLE: Visibility of a data object with statement scope
KEYWORDS: visibility, data object, statement scope, scope DEFECT TYPE: Erratum
STATUS: Included in corrigendum/complete

QUESTION:

Part 1:

Consider the following program:

MODULE mod
INTEGER, PARAMETER :: jmin(1:10) = (/ (i, i = 1, 10) /)
END MODULE

PROGRAM main
USE mod
INTEGER :: i

DO i = 1, 10
PRINT *, 'jmin(i) = ', jmin(i)
END DO

END PROGRAM

Some Fortran compilers consider the implied-DO variable I used in the module
to be visible to program units using the module and some Fortran compilers do
not consider the I to be visible to using program units.

Is an entity with statement scope in the specification part of a module
visible to a program unit using the module and accessing the public data of
the module as exemplified by the above example?

Part 2:

Consider the adaptation of the example program from Part 1:

MODULE mod
INTEGER, PARAMETER :: jmin(1:10) = (/ (i, i = 1, 10) /)
CONTAINS

SUBROUTINE one
i = 99 ! Is this a local or module variable?
! Compilers that export I probably say module
END SUBROUTINE

SUBROUTINE two
PRINT *, i
END SUBROUTINE

END MODULE

The module specification part uses the variable I as an implied-DO variable of
an array constructor. Module procedure ONE sets a variable named I to a
value.

Given:

* An implicitly declared data object in the module specification
part where the variable has statement scope, and

* An implicitly declared variable in a module procedure where the
variable has the same name as the variable described in the first
bullet of this list

is the variable in the module procedure a module variable (known to the entire
module and thus available outside the module) or is the variable local to the
module procedure?

ANSWER:
The implied-DO variable is not visible to the using program.
14.1.3 Statement Entities states, in part, that

The name of a variable that appears as the DO variable of an
implied-DO in a DATA statement or an array constructor has a
scope of the implied-DO list. It has the type and type
parameter that it would have if it were the name of a variable
in the scoping unit that includes the DATA statement or array
constructor and this type must be integer.

The words "would have if it were" were intended to convey the idea that the
existence of an array constructor or data implied-DO variable does not
actually cause an associated variable in the scoping unit to come into
existence.

Also, the following text appears in the same section (281:12-14):

If the name of a global or local entity accessible in the
scoping unit of a statement is the same as the name of a
statement entity in that statement, the name is interpreted
within the scope of the statement entity as that of the
statement entity.

The word "If" here implies that there need not be any such global or local
entity with the same name as that of the statement entity.

The first edit makes this clear. The second edit makes the same point for
FORALL statements and constructs.

EDITS:
Page 280, Clause 14.1.3, at the end of the first paragragh (280:44)
add:

The appearance of a name as the DO variable of an implied-DO in a
DATA statement or an array constructor is not an implicit
declaration of a variable whose scope is the scoping unit that
contains the statement.

Page 281, Clause 14.1.3, at the end of the second paragraph [281:4]
add:

The appearance of a name as an index-name in a FORALL statement or
FORALL construct is not an implicit declaration of a variable whose
scope is the scoping unit that contains the statement or construct.

SUBMITTED BY: Larry Rolison

HISTORY: 97-237 m143 submitted
00-158 m153 passed unanimously
00-254 m154 passed J3 letter ballot #2
00-Aug Oulu passed by WG5 {N1403}
00-Oct wg5 edits contained in corrigendum #1 {N1421}

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/

Sponsored Links