Fortran - intent(in)

Author

intent(in)

E. Robert Tisdale

2004-11-03, 3:56 am

> cat main.f90
subroutine f(x)
real, intent(out):: x
x = 13.0;
end subroutine f

subroutine g(x)
real, intent(in):: x
call f(x)
print *, 'x = ', x
end subroutine g

program main
real x
x = 33
print *, 'x = ', x
call g(x)
print *, 'x = ', x
end program main

> f90 -V -O3 -o main main.f90
f90: Copyright Absoft Corporation 1994-2002; \
Absoft Pro FORTRAN Version 8.0
f90fe: 19 source lines
f90fe: 0 Errors, 0 Warnings, 0 Other messages, 0 ANSI
> ./main
x = 33.0000
x = 13.0000
x = 13.0000

In the above example, program main calls subroutine g(x)
where argument x has intent(in) but
subroutine g(x) calls subroutine f(x)
where argument x has intent(out)
but no diagnostic message is produced.
Shouldn't the compiler warn the programmer
when a subprogram attempts to modify an argument with intent(in)?

Stig Kildegård Andersen

2004-11-03, 3:56 am

> Shouldn't the compiler warn the programmer
> when a subprogram attempts to modify an argument with intent(in)?

It probably would if the interface to subroutine f was explicit in
subroutine g. If you contain the subroutines in a module and use that
module, then I would expect a warning.

Kind Regards,
Stig Kildegård

Gareth Owen

2004-11-03, 3:56 am

"Stig Kildegård Andersen" <stigkildegaardatmaildotdk> writes:

>
> It probably would if the interface to subroutine f was explicit in
> subroutine g. If you contain the subroutines in a module and use that
> module, then I would expect a warning.

When wrapped in a module NAG f95 produces an error, not just a warning.

[gowen ~] f95 foo.f90
Error: foo.f90, line 12:
Argument X (no. 1) of F is OUT or INOUT but variable has INTENT(IN)
-----------------------------------------------------------------------------
module foo
contains
subroutine f(x)
real, intent(out):: x
x = 13.0;
end subroutine f

subroutine g(x)
real, intent(in):: x
call f(x)
print *, 'x = ', x
end subroutine g
end module foo
-----------------------------------------------------------------------------

--
Gareth Owen
A man,a plan,a canoe,pasta,heros,rajahs,a coloratura,maps,snipe,percale,
macaroni,a gag,a banana bag,a tan,a cat,a mane,paper,a Toyota rep,a pen,a mat,
a can,a tag,a banana bag again,(or a camel),a crepe,pins,spam,a rut,a Rolo,
cash,a jar,sore hats,a peon,a canal,Panama!

Herman D. Knoble

2004-11-03, 8:56 am

Salford FTN95 compile time diagnostic:
0008) call f(x)
*** The variable X appears where it can receive a value, in the call to F,
with argument 1 ('X') which has been declared as INTENT(OUT), yet it has
the INTENT(IN) attribute

Lahey LF95 compile time diagnostic:
Compiling program unit g at line 5:
2651-S: line 8: The actual argument of procedure f
procedure f shall be a definable that associates the
INTENT(IN) or INTENT(INOUT) dummy argument x.
The previous appearance is in line 1.
Compiling program unit main at line 11:

Skip Knoble

On Tue, 02 Nov 2004 19:03:58 -0800, "E. Robert Tisdale" <E.Robert.Tisdale@jpl.nasa.gov>
wrote:

-| > cat main.f90
-| subroutine f(x)
-| real, intent(out):: x
-| x = 13.0;
-| end subroutine f
-|
-| subroutine g(x)
-| real, intent(in):: x
-| call f(x)
-| print *, 'x = ', x
-| end subroutine g
-|
-| program main
-| real x
-| x = 33
-| print *, 'x = ', x
-| call g(x)
-| print *, 'x = ', x
-| end program main
-|
-| > f90 -V -O3 -o main main.f90
-| f90: Copyright Absoft Corporation 1994-2002; \
-| Absoft Pro FORTRAN Version 8.0
-| f90fe: 19 source lines
-| f90fe: 0 Errors, 0 Warnings, 0 Other messages, 0 ANSI
-| > ./main
-| x = 33.0000
-| x = 13.0000
-| x = 13.0000
-|
-|In the above example, program main calls subroutine g(x)
-|where argument x has intent(in) but
-|subroutine g(x) calls subroutine f(x)
-|where argument x has intent(out)
-|but no diagnostic message is produced.
-|Shouldn't the compiler warn the programmer
-|when a subprogram attempts to modify an argument with intent(in)?

Herman D. (Skip) Knoble, Research Associate
(a computing professional for 38 years)
Email: SkipKnobleLESS at SPAMpsu dot edu
Web: http://www.personal.psu.edu/hdk
Penn State Information Technology Services
Academic Services and Emerging Technologies
Graduate Education and Research Services
Penn State University
214C Computer Building
University Park, PA 16802-21013
Phone:+1 814 865-0818 Fax:+1 814 863-7049

Ian Bush

2004-11-03, 3:57 pm

E. Robert Tisdale wrote:

> subroutine f(x)
> real, intent(out):: x
> x = 13.0;
> end subroutine f
>
> subroutine g(x)
> real, intent(in):: x
> call f(x)
> print *, 'x = ', x
> end subroutine g
>

SNIP !

>
> In the above example, program main calls subroutine g(x)
> where argument x has intent(in) but
> subroutine g(x) calls subroutine f(x)
> where argument x has intent(out)
> but no diagnostic message is produced.
> Shouldn't the compiler warn the programmer
> when a subprogram attempts to modify an argument with intent(in)?

Quality of implementation issue. If the compiler can `see' both
f and g at the same time, for instance they are in the same file,
one might hope that it would catch such problems. But if it can not,
e.g. f and g are in different files and so when g is being compiled
the compiler may not know anything at all about f yet if f hasn't
been compiled. Even if f has been compiled I strongly suspect that
most compilers won't remember it, for in certain cases how can they ?

e.g.

f90 -c f.f90
f90 -c g.f90

is it somehow supposed to remember the interface details between
invocations ?

As others have pointed out if you have an implicit or ( correct ) explicit
interface in scope it is a different matter. Interfaces are a Good Thing !

Ian

Gordon Sande

2004-11-03, 3:57 pm

Ian Bush wrote:
> E. Robert Tisdale wrote:
>
>
>
>
> SNIP !
>
>
>
>
> Quality of implementation issue. If the compiler can `see' both
> f and g at the same time, for instance they are in the same file,
> one might hope that it would catch such problems. But if it can not,
> e.g. f and g are in different files and so when g is being compiled
> the compiler may not know anything at all about f yet if f hasn't
> been compiled. Even if f has been compiled I strongly suspect that
> most compilers won't remember it, for in certain cases how can they ?
>
> e.g.
>
> f90 -c f.f90
> f90 -c g.f90
>
> is it somehow supposed to remember the interface details between
> invocations ?
>
> As others have pointed out if you have an implicit or ( correct ) explicit
> interface in scope it is a different matter. Interfaces are a Good Thing !

Why isn't this a case of good old fashioned programmer error. If you
want to use the F90 features then you need an explicit interface which
can be either generated by contains in either the program or a module
or given by an interface block.

It is slightly more subtle than the usual case of having

real :: x(:)

and then wondering why the implicit interface call fails that traps
many initial F90 users who have "bad" habits from some other language
like F77.

(The official definitions of explicit and implicit interfaces do not
match common usage and seem to cause no end of problem. Implicit is
"no interface" and explicit is either the result of being contained
in program/module or the (awkward) interface block if I have gotten
it straight.)

> Ian
>

Jugoslav Dujic

2004-11-03, 3:57 pm

Gordon Sande wrote:
|
| (The official definitions of explicit and implicit interfaces do not
| match common usage and seem to cause no end of problem. Implicit is
| "no interface" and explicit is either the result of being contained
| in program/module or the (awkward) interface block if I have gotten
| it straight.)

Seconded. What on Earth was wrong with the word "Prototype(d)"?
Whenever I say "explicit interface" to a relative newbie, he would
think he needs an INTERFACE block. A sentence:

"This routine is not prototyped, but it should be."

sounds IMO much clearer than

"This routine does not have an explicit interface [in the caller], but
it should."

Yeah I know Standardese has its merits, but the problem occurs when
Standardese leaks into the world of common usage. There, you better
be a tad less accurate but more descriptive.

--
Jugoslav
___________
www.geocities.com/jdujic

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Richard E Maine

2004-11-03, 3:57 pm

Gordon Sande <g.sande@worldnet.att.net> writes:

> (The official definitions of explicit and implicit interfaces do not
> match common usage and seem to cause no end of problem. Implicit is
> "no interface" and explicit is either the result of being contained
> in program/module or the (awkward) interface block if I have gotten
> it straight.)

Yes, you have it straight. As a memory aid, think of it as just
like variable types.

Explicit is when you supply the information to the compiler. In the
case of a variable type, you have a type declaration statement; in the
case of an interface it is when you either write an interface body
or a USE statement to tell the compiler what's up.

Implicit is when the compiler deduces the information implicitly.
For a variable type, the deduction is based on teh first letter of
the variable name. For an interface, the deduction is based on
what the invocation of the procedure looks like. For example if the
invocation looke like call sub(x,y) where x and y are real, then
the compiler implicitly deduces that sub better be a subroutine with
2 real arguments.

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

Paul Van Delst

2004-11-03, 3:57 pm

Jugoslav Dujic wrote:
> Gordon Sande wrote:
> |
> | (The official definitions of explicit and implicit interfaces do not
> | match common usage and seem to cause no end of problem. Implicit is
> | "no interface" and explicit is either the result of being contained
> | in program/module or the (awkward) interface block if I have gotten
> | it straight.)
>
> Seconded. What on Earth was wrong with the word "Prototype(d)"?
> Whenever I say "explicit interface" to a relative newbie, he would
> think he needs an INTERFACE block. A sentence:
>
> "This routine is not prototyped, but it should be."
>
> sounds IMO much clearer than
>
> "This routine does not have an explicit interface [in the caller], but
> it should."

Not to be a contrarian, but I have the exact opposite opinion. :o) The first statement,
using the word "prototype", has little meaning for me. The second form seems quite clear.

When I "prototype" a routine, it usually means I code it up in IDL or matlab to see how it
interacts with the greater whole (and it makes it easy to plot any final or intermediate
results) and/or whether the algorithm I am using is doing the job, i.e. results within
tolerances, numerical stability, etc.

> Yeah I know Standardese has its merits, but the problem occurs when
> Standardese leaks into the world of common usage. There, you better
> be a tad less accurate but more descriptive.

In this context, I think your statement above is more applicable to the word "prototype"
than "interface".

Just my C-inexperienced $0.02, of course.

cheers,

paulv

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

Gordon Sande

2004-11-03, 3:57 pm

Paul Van Delst wrote:
> Jugoslav Dujic wrote:
>
>
>
> Not to be a contrarian, but I have the exact opposite opinion. :o) The
> first statement, using the word "prototype", has little meaning for me.
> The second form seems quite clear.

I would guess that the words without careful definition would come out
something like explicit interface is one of those (#@%!) interface
blocks and an implicit interface is what you get by using a module
(or contains) and no interface is good old F77. After you accumulate
a bit of scar tissue you figure out that implicit means the compiler
gets to guess based on exactly and only the call statement and explicit
means that you are using a module so the compile has left a "mod" file
behind (and interface blocks are such an abomination that they are best
forgotten as they are an awkward solution to what would be a technical
loophole in the standard). And routines contained in other routines is
for those who used to program in Pascal. ;-) Or you can read the manual
which explains it. Or you can ask c.l.f and get a few wry remarks and an
understandable clarification from (many thanks to) Richard.

Prototype must be a slightly slower version of rapid prototype which
is modern talk for quick and dirty solution without attention to the
more subtle cases.

> When I "prototype" a routine, it usually means I code it up in IDL or
> matlab to see how it interacts with the greater whole (and it makes it
> easy to plot any final or intermediate results) and/or whether the
> algorithm I am using is doing the job, i.e. results within tolerances,
> numerical stability, etc.
>
>
>
> In this context, I think your statement above is more applicable to the
> word "prototype" than "interface".
>
> Just my C-inexperienced $0.02, of course.
>
> cheers,
>
> paulv
>

Richard E Maine

2004-11-03, 3:57 pm

Paul Van Delst <paul.vandelst@noaa.gov> writes:

> Not to be a contrarian, but I have the exact opposite opinion. :o) The
> first statement, using the word "prototype", has little meaning for
> me. The second form seems quite clear.

Yes. In the standards business, it pretty quickly becomes evident
that what is obvious and intuitive to one person is cryptic to
another, and visa versa. This happens a lot. Heck, sometimes
it varies even for a single person as a function of time.

I know that I used to be horribly

about the various different
special forms of expressions - initialization expressions, specification
expressions, etc. It wasn't so much the detailed requirements (which
are pretty complicated), but just the general notion of what the role
of the different kinds of expressions were. I could never remember
where you needed what kinds of expressions and thought it all horribly
confusing. I remember finding it horribly confusing... but somehow
it all makes sense to me and seems reasonably intuitive to me now.

And once I get the intuitive idea of what the roles of the various
cases are, then a lot of the details become intuitive (not all of
them, but a lot).

Partly, I think it has gotten simpler than in earlier versions of the
standard. There are really only 2 special kinds of expressions any
more - initialization expressions and specification expressions.
Initialization expressions are for things that need to be known at
compile time (like initializations), and specification expressions
are for things that need to be known on entry to a procedure (namely
specifications). There used to also be constant expressions... which
were sort of like initialization expressions, but not quite. And
there are also restricted expressions, but it turns out that those
are just a stepping stone to formally describing specification
expressions - you don't really need to pay much attention to
restricted expressions as a separate thing.

But I suspect that a big part of the change is in me. My intuition
finally picked it up somewhere along the line and now I have trouble
remembering why it didn't seem intuitive before.... but I still do
remember that it didn't seem intuitive.

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

Dan Tex1

2004-11-03, 8:56 pm

From: "Jugoslav Dujic" jdujic@yahoo.com

>Gordon Sande wrote:
>|
>| (The official definitions of explicit and implicit interfaces do not
>| match common usage and seem to cause no end of problem. Implicit is
>| "no interface" and explicit is either the result of being contained
>| in program/module or the (awkward) interface block if I have gotten
>| it straight.)
>
>Seconded. What on Earth was wrong with the word "Prototype(d)"?
>Whenever I say "explicit interface" to a relative newbie, he would
>think he needs an INTERFACE block. A sentence:
>
>"This routine is not prototyped, but it should be."
>
>sounds IMO much clearer than

My guess is that the majority of fortran programmers will have no clude what
you mean when you say "prototyped".

Dan :-)

>"This routine does not have an explicit interface [in the caller], but
>it should."
>
>Yeah I know Standardese has its merits, but the problem occurs when
>Standardese leaks into the world of common usage. There, you better
>be a tad less accurate but more descriptive.
>
>--
> Jugoslav

Sponsored Links