A common structure in f90 is

================
module precision
   integer, parameter :: rdp=8
end module precision

module globals
   use precision
   real(rdp) foo
end module globals

program main
  use precision       ! < not really needed?
  use globals

  real(rdp) local_variable
  :
end program main
==============

I was wondering. Is the "use precision" statement in program main
needed? Module globals already USEs precision so main has access to
rdp through globals without the "use precision" statement.

Is it an error to give main access to rdp in two ways like this? rdp
is included into main in two ways: directly through "use precision"
and indirectly through "use globals". Is this aliasing? Would it be
illegal to alter rdp (if it wasn't a parameter)?

On Sep 30, 4:21=A0pm, The Star King <j...@npl.co.uk> wrote:
> A common structure in f90 is
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> module precision
> =A0 =A0integer, parameter :: rdp=3D8
> end module precision
>
> module globals
> =A0 =A0use precision
> =A0 =A0real(rdp) foo
> end module globals
>
> program main
> =A0 use precision =A0 =A0 =A0 ! < not really needed?
> =A0 use globals
>
> =A0 real(rdp) local_variable
> =A0 :
> end program main
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> I was wondering. Is the "use precision" statement in program main
> needed? Module globals already USEs precision so main has access to
> rdp through globals without the "use precision" statement.
>
> Is it an error to give main access to rdp in two ways like this? rdp
> is included into main in two ways: directly through "use precision"
> and indirectly through "use globals". Is this aliasing? Would it be
> illegal to alter rdp (if it wasn't a parameter)?

The program is legal with or without the use precision in the main
program. In a more complicated program you might get name clashes that
then require recourse to the only: clause.

You cannot alter the value of rdp as it's a named constant, and that
is required when a constant is used as a kind type specifier.

Regards,

Mike Metcalf

On Sep 30, 3:41=A0pm, m_b_metcalf <michaelmetc...@compuserve.com> wrote:
> On Sep 30, 4:21=A0pm, The Star King <j...@npl.co.uk> wrote:
>
>
>
>
>
> > A common structure in f90 is
>
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > module precision
> > =A0 =A0integer, parameter :: rdp=3D8
> > end module precision
>
> > module globals
> > =A0 =A0use precision
> > =A0 =A0real(rdp) foo
> > end module globals
>
> > program main
> > =A0 use precision =A0 =A0 =A0 ! < not really needed?
> > =A0 use globals
>
> > =A0 real(rdp) local_variable
> > =A0 :
> > end program main
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> > I was wondering. Is the "use precision" statement in program main
> > needed? Module globals already USEs precision so main has access to
> > rdp through globals without the "use precision" statement.
>
> > Is it an error to give main access to rdp in two ways like this? rdp
> > is included into main in two ways: directly through "use precision"
> > and indirectly through "use globals". Is this aliasing? Would it be
> > illegal to alter rdp (if it wasn't a parameter)?
>
> The program is legal with or without the use precision in the main
> program. In a more complicated program you might get name clashes that
> then require recourse to the only: clause.
>
> You cannot alter the value of rdp as it's a named constant, and that
> is required when a constant is used as a kind type specifier.
>
> Regards,
>
> Mike Metcalf- Hide quoted text -
>
> - Show quoted text -

Thanks, Mike. If I add a variable like mass to precision and
initialize it:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module precision
   integer, parameter :: rdp=3D8
   real mass=3D3
end module precision


module globals
   use precision
   real(rdp) foo
end module globals


program main
  use precision       ! < not really needed?
  use globals


  real(rdp) local_variable

  mass=3D1

end program main
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Is it legal to set the value of mass as shown? I am worried because
mass has been passed to main two ways which raises the issue of
alisaing.

Thanks for your help

The Star King wrote:
> On Sep 30, 3:41 pm, m_b_metcalf <michaelmetc...@compuserve.com> wrote:
>> On Sep 30, 4:21 pm, The Star King <j...@npl.co.uk> wrote:
>>
>>
>>
>>
>>
>>> A common structure in f90 is
>>> ================
>>> module precision
>>>    integer, parameter :: rdp=8
>>> end module precision
>>> module globals
>>>    use precision
>>>    real(rdp) foo
>>> end module globals
>>> program main
>>>   use precision       ! < not really needed?
>>>   use globals
>>>   real(rdp) local_variable
>>>   :
>>> end program main
>>> ==============
>>> I was wondering. Is the "use precision" statement in program main
>>> needed? Module globals already USEs precision so main has access to
>>> rdp through globals without the "use precision" statement.
>>> Is it an error to give main access to rdp in two ways like this? rdp
>>> is included into main in two ways: directly through "use precision"
>>> and indirectly through "use globals". Is this aliasing? Would it be
>>> illegal to alter rdp (if it wasn't a parameter)?
>> The program is legal with or without the use precision in the main
>> program. In a more complicated program you might get name clashes that
>> then require recourse to the only: clause.
>>
>> You cannot alter the value of rdp as it's a named constant, and that
>> is required when a constant is used as a kind type specifier.
>>
>> Regards,
>>
>> Mike Metcalf- Hide quoted text -
>>
>> - Show quoted text -
> 
> Thanks, Mike. If I add a variable like mass to precision and
> initialize it:
> 
> ================
> module precision
>    integer, parameter :: rdp=8
>    real mass=3
> end module precision
> 
> 
> module globals
>    use precision
>    real(rdp) foo
> end module globals
> 
> 
> program main
>   use precision       ! < not really needed?
>   use globals
> 
> 
>   real(rdp) local_variable
> 
>   mass=1
> 
> end program main
> ==============
> 
> Is it legal to set the value of mass as shown? I am worried because
> mass has been passed to main two ways which raises the issue of
> alisaing.
> 
> Thanks for your help
Yes, it's legal to alter the value of mass.  It's not really
accessed two ways.  In both cases it comes from the module
and it's visible to the compiler.  The prohibition against
modifying aliased variables applies to hidden aliases.
Otherwise, things like
    A(I) = A(J) + 1
would have a strange set of rules and even EQUIVALENCE
or COMMON wouldn't work :(.

I think the only way you can get into trouble with the
anti-alias rule is with a dummy argument as one of
the alias set.

Dick Hendrickson

The Star King <jfb@npl.co.uk> wrote:
[code elided]
> Is it legal to set the value of mass as shown? I am worried because
> mass has been passed to main two ways which raises the issue of
> alisaing.

Yes, it is legal. I seem to recall that there was an interp on this kind
of question long ago, probably in early f90 days. In this kind of case,
the compiler has the information to know that it is actually the same
variable; it doesn't count as the kind of duplication that causes
modification to be disallowed.

I don't recall the details of how the wording of the standard supports
this. I'd have to take a bit of time to feret that out. But I'm quite
sure of the result; this kind of thing is very common practice.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On Sep 30, 4:10=A0pm, nos...@see.signature (Richard Maine) wrote:
> The Star King <j...@npl.co.uk> wrote:
> [code elided]
>
> > Is it legal to set the value of mass as shown? I am worried because
> > mass has been passed to main two ways which raises the issue of
> > alisaing.
>
> Yes, it is legal. I seem to recall that there was an interp on this kind
> of question long ago, probably in early f90 days. In this kind of case,
> the compiler has the information to know that it is actually the same
> variable; it doesn't count as the kind of duplication that causes
> modification to be disallowed.
>
> I don't recall the details of how the wording of the standard supports
> this. I'd have to take a bit of time to feret that out. But I'm quite
> sure of the result; this kind of thing is very common practice.
>
> --
> Richard Maine =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Good judgment come=
s from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle =A0 =A0 =A0 =A0 =A0 | =A0-- Mark Twain

Thanks very much for everyone's help on this. Yes, it is extremely
common practice which is why I was worried! Personally I prefer not to
put USE statements in the global scope of modules as every program
unit that USEs the module then access everything it USEd and so on
(creating a potentially unsafe cascade). That is, I prefer,

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module foo

contains

subroutine bar
  use globals
end subroutine bar

subroutine two
  use globals
end subroutine two

end module foo
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

rather than

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module foo
  use globals
contains

subroutine bar
end subroutine bar

subroutine two
end subroutine two

end module foo
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The second example is shorter but it does mean that everything USEing
foo will also gain access to the content of globals. It's then easy to
get confused over which program unit knows what.

The Star King <jfb@npl.co.uk> wrote:

> Personally I prefer not to
> put USE statements in the global scope of modules as every program
> unit that USEs the module then access everything it USEd and so on
> (creating a potentially unsafe cascade).

I prefer the opposite because I like the global scope of the module to
have all the information about the module's interaction with other
things, including what other modules it depends on. I've known people
who preferred both styles, though; I won't claim there is anything
objectively wrong with either one.

I will note that it is recommended by most people (certainly including
myself, and it seems to be a majority opinion) that you use a global
PRIVATE statement in the scoping unit of each module. I rather wish that
had been the language default, but it is a bit late for that. Then
nothing from the module is exported except for those things that you
explicitly give the PUBLIC attribute to.

This practice avoids the cascade that you are referring to, but it is
recommended as general practice even when you don't have USE statements
in the global scope. It just generally gives you much better control
over and explicit documentation in the code of exactly what your module
exports. You don't end up accidentally exporting something.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On Sep 30, 4:42=A0pm, nos...@see.signature (Richard Maine) wrote:
> The Star King <j...@npl.co.uk> wrote:
>
> > Personally I prefer not to
> > put USE statements in the global scope of modules as every program
> > unit that USEs the module then access everything it USEd and so on
> > (creating a potentially unsafe cascade).
>
> I prefer the opposite because I like the global scope of the module to
> have all the information about the module's interaction with other
> things, including what other modules it depends on. I've known people
> who preferred both styles, though; I won't claim there is anything
> objectively wrong with either one.
>
> I will note that it is recommended by most people (certainly including
> myself, and it seems to be a majority opinion) that you use a global
> PRIVATE statement in the scoping unit of each module. I rather wish that
> had been the language default, but it is a bit late for that. Then
> nothing from the module is exported except for those things that you
> explicitly give the PUBLIC attribute to.
>
> This practice avoids the cascade that you are referring to, but it is
> recommended as general practice even when you don't have USE statements
> in the global scope. It just generally gives you much better control
> over and explicit documentation in the code of exactly what your module
> exports. You don't end up accidentally exporting something.
>
> --
> Richard Maine =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Good judgment come=
s from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle =A0 =A0 =A0 =A0 =A0 | =A0-- Mark Twain

So if I use:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
module foo
  use globals
  private
  public bar,two
contains

  subroutine bar
  end subroutine bar

  subroutine two
  end subroutine two

end module foo
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The whatever USEs foo will not have access to globals? I didn't know
that, I thought private would only refer to objects explicitly
mentioned in foo.

The Star King <jfb@npl.co.uk> wrote:

> So if I use:
> 
> ============
> module foo
>   use globals
>   private
>   public bar,two
> contains
> 
>   subroutine bar
>   end subroutine bar
> 
>   subroutine two
>   end subroutine two
> 
> end module foo
> ===========
> 
> The whatever USEs foo will not have access to globals?

Correct.

> I didn't know
> that, I thought private would only refer to objects explicitly
> mentioned in foo.

Nope. It sets the default accessibility for everything known in the
global scope of foo.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

"The Star King" <jfb@npl.co.uk> wrote in message 
news:f30e71bd-1d07-49a3-95c5-1daf8cb5df99@e12g2000yqi.googlegroups.com...
|A common structure in f90 is
|
| ================
| module precision
|   integer, parameter :: rdp=8

This isn't portable.
Better to use SELECTED_REAL_KIND or KIND(0.0d0).

| end module precision
|
| module globals
|   use precision
|   real(rdp) foo
| end module globals