fortran sensibility at specification order
in [Fortran]
|
From: cjpsimon on 20 Oct 2009 12:19 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 20 Oct 2009 12:51 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 20 Oct 2009 13:34 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 20 Oct 2009 14:26 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 20 Oct 2009 14:53
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 |