Re: type/rank mismatch error

Richard Maine wrote:
| Jugoslav Dujic <jdujic@xxxxxxxxx> wrote:
|
|| estevino@xxxxxxxxx wrote:
| ...[module calulate, which defines some_op]
||| MODULE various
||| USE calculate
||| CONTAINS
||| SUBROUTINE number1(x,y,some_op)
||| ...
||| END SUBROUTINE number1
||| SUBROUTINE number2(x,y,some_op)
||| ...
||| END SUBROUTINE number2
||| END MODULE various
|
|| I must say I'm confused as to the intent of the code. The code, as shown,
|| violates the simple rule that
||
|| *Any formal (dummy) argument of a routine must be declared locally
|| in the routine, not elsewhere*
|
| Um. I'm confused by that "rule". I think I know what you mean, but the
| expression of it confuses me. You can, of course, define things of that
| same name elsewhere all you want.That just doesn't constitute defining
| the dummy argument.
|
|| in other words, if you defined some_op in the module "calculate", you
|| must not redefine some_op elsewhere (at least, not in a scope which
|| USEs the module "calculate")
|
| True, but the code shown doesn't do that. It defines some_op in module
| procedures that are *NOT* in the same scope as the USE statement. It
| makes a huge difference. See host association. The use of those names as
| dummy arguments blocks the host association of the name imported by the
| USE.

I overlooked the fact that, in case of host association, the local
declaration overrides the host-associated declaration. Thus, one
may have two different entities of the same name "accessible" (for
want of a better word) in the same scope, but only the one from the
inner scope will be visible and usable.

The OP didn't show us enough code to confirm the meaning of some_op
as the dummy argument of number1. From the naming and explanation,
I judged that the intent was "use declaration as from module calculate"
rather than "use the local declaration, overriding the one from
host-association".

Still, I don't see what's wrong with the rule as written: the *entity*
referred to by formal argument must be declared in the routine itself
(let's put the issue of implicit typing aside); it is local to the
routine ab definitio. Other same-named entities may or may not exist
in the host scope, but they won't be accessible anyway.

In any case, avoiding re-using the same name for different entities
in inner and outer scope is a good rule of thumb (I overlooked the
overriding thingo as I use that rule of thumb myself, so tend to
forget that it's allowable).

[Please, pardon my loose usage of standardese above; while I'm familiar
with it, I'm not always able to find the exact precise wording on my own.
I hope that the message does get through though.]

--
Jugoslav
___________
www.xeffort.com

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

Relevant Pages

  • Re: use module to pass data between procedures
    ... containing that declaration. ...  The scope of the module variable SZ ...
    (comp.lang.fortran)
  • Scope of "implicit none" and interfaces - rationale?
    ... subroutine foo ... end interface ... Is there a fundamental reason why the scope of a useful declaration like ...
    (comp.lang.fortran)
  • Re: allocatable array from subroutine
    ...  Then delete the declaration for my_arr from within the subroutine. ... The array my_arr will then have a scope within both the main program and the subroutine. ...
    (comp.lang.fortran)
  • Re: allocatable array from subroutine
    ...  Then delete the declaration for my_arr from within the subroutine. ... The array my_arr will then have a scope within both the main program and the subroutine. ...
    (comp.lang.fortran)
  • compiling kernel
    ... scripts/kconfig/qconf.h:51: error: `e' was not declared in this scope ... scripts/kconfig/qconf.h:73: error: `int updateList' redeclared as different ... scripts/kconfig/qconf.h:8: error: forward declaration of `class ConfigList' ... ConfigLineEdit' ...
    (alt.os.linux.suse)