Control host association

From: James Giles (jamesgiles_at_worldnet.att.net)
Date: 06/30/04 

Date: Tue, 29 Jun 2004 22:34:47 GMT

I've said before that new features for the next revision
of the standard beyond F2003 should be discussed as
widely ass possible is a public forum. So, here's a first
entry in such a discussion.

Internal procedures are quite useful and I code with them
all the time. The trouble is that host association rules are
just about backwards from what I want.

Suppose I have a procedure that has two other procedures
internal to it. Schematically:

   Subroutine sub1(...)
   ...
   Contains
      Subroutine sub2(...)
         ...
      End subroutine sub2
      Subroutine sub3(...)
         ...
         VAR = ...
         ...
      End subroutine sub3
   End subroutine sub1

If, in sub3, I reference or define a variable VAR but forget
to declare it within sub3, even if sub3 has IMPLICIT NONE,
VAR will be associated with any item in the host by that
name. That's useful if I *want* such host association, so
I don't want to prevent that mechanism from being permitted.
But, there's no way to tell the compiler *not* to do that.

Not only that, suppose that sub2 does not specify IMPLICIT
NONE and neither does sub1, even if there is no VAR used
anywhere in sub1, an implicitly declared instance in sub2
will be shared with my inadvertently undeclared instance in
sub3 - again, even if sub3 *does* have IMPLICIT NONE!

And, of course, even if it's never actually used or mentioned
in sub1, any module sub1 USEs may have supplied a declaration
of VAR which I'll inadvertently end up associated with.

There is another proposal to permit internel procedures to
be nested arbitrarily deeply. If that is adopted, this problem
will be much worse.

This isn't often a problem, but when it s, it can be difficult
to identify. Consequently, I always separately compile
internal procedures as if they were externals before moving
them into their host code. Anything that shows up as undeclared
in the separate compile that I *don't* intend to share with the
host is really an error.

Well, if there were some control over host association similar
to the ONLY clause of the USE statement, I would not have to
go through this troublesome extra step. I have two proposals
to address this problem.

First, use the IMPORT keyword (introduced in F2003 to
explicitly permit host association in another context) to
control host association for internal procedures. If the
program doesn't use the IMPORT statement, the rules
would remain the same as F2003 (basically the same as
F95 for this issue). If an internal procedure has an
IMPORT statement without an ONLY clause or a import
name list, the meaning is the same as if it wasn't there:
all relevant entities are imported. IMPORT can have
a list of names on the statement, in which case only those
names are imported. I recomment the addition of a
form with an ONLY keyword;

   IMPORT ONLY: rename-list

The syntax is deliberately similar to the USE statement. This
permits an empty ONLY list, which means nothing is imported
by host association. And, you can rename host entities while
importing them.

With a combination of IMPORT ONLY and IMPLICIT NONE
it will permit the compiler to catch *all* undeclared local
variables in an internal procedure. 

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

Relevant Pages

  • Re: Statement function host association
    ... procedures inside of internal procedures. ... 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. ... SUBROUTINE sub1 ...
    (comp.lang.fortran)
  • Re: Statement function host association
    ... >> procedures inside of internal procedures. ... > not override host association, so the compiler cannot help you ... there should be a simple way of excluding some or all host ... FUNC1, then X within SUB1 can be accessed as SUB1%X from ...
    (comp.lang.fortran)