From: cjpsimon on

When I compile with gfortran (gcc 4.4) this fragment of code alone :

file : test.f90

Subroutine getpar (par, amax)
Integer par(amax)
Integer amax
End

gfortran -c test.f90

I get

test.f90:3.15:
Integer amax
1
Error: Symbol 'amax' at (1) already has basic type of REAL

test.f90:2.15:
Integer par(amax)
1
Error: Expression at (1) must be of INTEGER type, found REAL

test.f90:2.15:
Integer par(amax)
1
Error: Expression at (1) must be of INTEGER type, found REAL

I suspect an error in gfortran :

It seems that amax is known as REAL before being declared as INTEGER.

If I change the statments order or if I add Implicit none
all is well.

As I remember, fortran had no sensibility at specification order !!!
May be I am wrong ?

From: Richard Maine on
cjpsimon(a)gmail.com <cjpsimon(a)gmail.com> wrote:

> Subroutine getpar (par, amax)
> Integer par(amax)
> Integer amax
> End
[gives errors because of the order of the declarations]

> I suspect an error in gfortran :

I disagree

> If I change the statments order or if I add Implicit none
> all is well.

Changing the order should work. The code is still illegal with implicit
none, but that doesn't mean that a compiler could not accept it as an
extension.

> As I remember, fortran had no sensibility at specification order !!!
> May be I am wrong ?

I think you mean "sensitivity" instead of "sensibility". It is perhaps
arguable how sensible the restrictions are, but they definitely are
sensitive to ordering. :-)

Order does not matter for some things, but it does for others. I have
heard proposals to substantially liberalize the ordering requirements,
partly in order to make them simpler. You cannot completely remove them.
Otherwise it is trivial to construct ambiguous examples. A trivial case
is

real(kind(x)) :: y
real(kind(y)) :: x

Other cases can get far more subtle and messy.

For my personal style, I try to follow the general rule of declaring
things before they are used. That keeps me from having to remember
exactly which cases require that and which ones don't. There are some
situations where it isn't possible to declare everything before use;
fortunately, those are among the cases where you don't have to. (A
notable example is two derived types with pointer components to each
other).

Your example is prohibited by the following requirement in f2003. There
are simillar requirements in earlier standards. The penultimate
paragraph of 7.1.6 reads:

"A variable in a specification expression shall have its type and type
parameters, if any, specified by a previous declaration in the same
scoping unit, bythe implicit typing rules in effect for the scoping
unit, or by host or use association. If a variable in a specification
expression is typed by the implicit typing rules, its appearance in any
subsequent type declaration statement shall conform the implied type and
type parameters."

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: steve on
On Oct 20, 9:51 am, nos...(a)see.signature (Richard Maine) wrote:
> cjpsi...(a)gmail.com <cjpsi...(a)gmail.com> wrote:
> > Subroutine getpar (par, amax)
> >    Integer par(amax)
> >    Integer amax
> > End
>
> [gives errors because of the order of the declarations]
>
> > I suspect an error in gfortran :
>
> I disagree
>
> > If I change the statments order or if I add Implicit none
> > all is well.
>
> Changing the order should work. The code is still illegal with implicit
> none, but that doesn't mean that a compiler could not accept it as an
> extension.
>

It's an extension. After adding 'IMPLICIT NONE', gfortran will
produce
an error with -std=f95.

troutmask:sgk[241] gfc4x -c -std=f95 mn.f90
mn.f90:3.15:

integer par(amax)
1
Error: Extension: Symbol 'amax' is used before it is typed at (1)
mn.f90:1.22:

subroutine getpar (par, amax)
1
Error: Symbol 'par' at (1) has no IMPLICIT type

--
steve
From: cjpsimon on
Thanks for your explanation.

My style was to declare dummy arguments in the order of occurence
in subroutine declaration.

It's a case where my style is out :-)


On 20 oct, 18:51, nos...(a)see.signature (Richard Maine) wrote:
> cjpsi...(a)gmail.com <cjpsi...(a)gmail.com> wrote:
> > Subroutine getpar (par, amax)
> >    Integer par(amax)
> >    Integer amax
> > End
>
> [gives errors because of the order of the declarations]
>
> > I suspect an error in gfortran :
>
> I disagree
>
> > If I change the statments order or if I add Implicit none
> > all is well.
>
> Changing the order should work. The code is still illegal with implicit
> none, but that doesn't mean that a compiler could not accept it as an
> extension.

Extentions are so dangerous :-)

My code compiled with others compilers. It's the first time I see this
issue.
It's a good thing that version of gfortran gave an error !

>

It's ok : I changed the order.

> > As I remember, fortran had no sensibility at specification order !!!
> > May be I am wrong ?
>
> I think you mean "sensitivity" instead of "sensibility". It is perhaps
> arguable how sensible the restrictions are, but they definitely are
> sensitive to ordering. :-)
>

Sorry for my poor english :-(

> Order does not matter for some things, but it does for others. I have
> heard proposals to substantially liberalize the ordering requirements,
> partly in order to make them simpler. You cannot completely remove them.
> Otherwise it is trivial to construct ambiguous examples. A trivial case
> is
>
>   real(kind(x)) :: y
>   real(kind(y)) :: x
>
> Other cases can get far more subtle and messy.
>
> For my personal style, I try to follow the general rule of declaring
> things before they are used. That keeps me from having to remember
> exactly which cases require that and which ones don't. There are some
> situations where it isn't possible to declare everything before use;
> fortunately, those are among the cases where you don't have to. (A
> notable example is two derived types with pointer components to each
> other).
>

Is there any solution in that case ?
May be a pointer to an abstract type or other mean ?

> Your example is prohibited by the following requirement in f2003. There
> are simillar requirements in earlier standards. The penultimate
> paragraph of 7.1.6 reads:
>
>  "A variable in a specification expression shall have its type and type
> parameters, if any, specified by a previous declaration in the same
> scoping unit, bythe implicit typing rules in effect for the scoping
> unit, or by host or use association. If a variable in a specification
> expression is typed by the implicit typing rules, its appearance in any
> subsequent type declaration statement shall conform the implied type and
> type parameters."
>

Ok, I see the requirement. Thank you for the point.

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

From: Richard Maine on
cjpsimon(a)gmail.com <cjpsimon(a)gmail.com> wrote:

> Thanks for your explanation.
>
> My style was to declare dummy arguments in the order of occurence
> in subroutine declaration.
>
> It's a case where my style is out :-)

There was a time long ago when I also used that choice. In the pre-f77
days, I didn't pay much attention to standards. (Neither did most people
in those days; people typically programmed for the one computer they had
access to at the time.) I don't believe I even saw a copy of the f66
standard until well after f77 was out. It worked on whatever compiler I
was using, so that was ok. I've changed (in many ways - not all related
to Fortran) since then.

> > There are some
> > situations where it isn't possible to declare everything before use;
> > fortunately, those are among the cases where you don't have to. (A
> > notable example is two derived types with pointer components to each
> > other).
> >
> Is there any solution in that case ?
> May be a pointer to an abstract type or other mean ?

That is a case where the declaration before use is allowed, so the
solution is to do so in that case, as in

type one
type(two), pointer :: x
end type

type two
type(one), pointer :: y
end type

That use of type(two) before the declaration of two is a case where you
can't easily get around the use before declaration, but is ok in the
standard. It is important that the x component here must be a pointer
(or allocatabe, though an oversight in f2003 disallowed that - an
oversight which I believe has since been fixed). But then if both the x
and y components were non-pointers, the construct would be infinite,
which would be a problem for other reasons than just the Fortran
standard.

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