forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Fortran 2003 and 2008 features
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Fri Aug 12, 2022 8:38 pm    Post subject: Reply with quote

Thank you, Paul, I can see that now.

A rather artificial test program to try sometime:

Code:
program test
  implicit none
  integer, parameter ::dp=kind(1.d0)
  integer  j
  print*, 'j [i.e. sqrt(-1)] raised to powers 1, 2, 3, and 4'
  do j = 1, 4, 1
    associate( j => cmplx(0.d0,1.d0,kind=dp)**j )
    print*, j
    end associate
  end do
end program test
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Aug 23, 2022 2:32 am    Post subject: Reply with quote

More twists from Fortran language nazis.

1) Found such pieces in their codes
Code:
       call af_particles_to_grid(tree, i_pos_ion, n_photons, &
            get_id, get_rw, interpolation_order_to_density, &
            iv_tmp=i_tmp_dens, offset_particles=n_part_before)


and made simple demo test
Code:
Program test
Real a, b
b=1
Call sub1 (a=b)
end program

subroutine sub1(A)
Print*,A
End subroutine


which gives the following error report
Code:
*** SUB1 has an implicit interface and cannot have keyword arguments (possible


Is this useful modern Fortran feature or just an usual perversion which makes code unreadable and often just plain slower?

2) What for IMPORT is used here?
Code:
    interface
       !> Function that returns a scalar
       real(dp) function box_func(box)
         import
         type(box_t), intent(in) :: box
       end function box_func

       !> Reduction method (e.g., min, max, sum)
       real(dp) function reduction(a, b)
         import
         real(dp), intent(in) :: a, b
       end function reduction
    end interface


Is it supported by FTN95 ?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Aug 23, 2022 9:00 am    Post subject: Reply with quote

1) The error report in the simple demo test is correct. An explicit interface is required in this context.

2) IMPORT is supported but it is a recent addition. Please report any failures.
Back to top
View user's profile Send private message AIM Address
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Tue Aug 23, 2022 9:29 am    Post subject: Reply with quote

Dan,

SUB1 is not an internal routine i.e. contained in the program or a module. As it is an external routine it must be listed in an interface block.

So there are four ways to make this code work:

Add an interface block:
Code:
Program test
Real a, b
interface
  subroutine sub1(A)
  real A
  end subroutine sub1
end interface
b=1
Call sub1 (a=b)
end program

subroutine sub1(A)
Print*,A
return
End subroutine


Move SUB1 to a new CONTAINS section in the main program
Code:
Program test
Real a, b
b=1
Call sub1 (a=b)
contains
  subroutine sub1(A)
  Print*,A
  End subroutine
end program

Put everything in a module
Code:
module demo
contains
subroutine test
Real a, b
b=1
Call sub1 (a=b)
end subroutine test
subroutine sub1(A)
Print*,A
End subroutine
end module demo

program p
use demo
call test
end program p


Put SUB1 in a module and USE the module in the main program:
Code:
module demo
contains
subroutine sub1(A)
Print*,A
End subroutine
end module demo

program test
use demo
Real a, b
b=1
Call sub1 (a=b)
end program test
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Aug 23, 2022 7:33 pm    Post subject: Reply with quote

Paul, Ken,
Thanks but my question was about rationale of doing this unusual and hence confusing thing.

Why not do this obvious way which will not require any trickery with modules, interfaces which are just causing the code to be bloated and less readable?
Code:
Program test
Real a, b
b=1
a=b
Call sub1 (a)
end program

subroutine sub1(A)
Print*,A
End subroutine


Or this error was because Fortran does not check subroutine arguments when it is called on types consistency so that the code does not know if A and B are functions or regular variables? If people think that the ability to call sub1(a=b) is an useful addition to Fortran (to make crazy nazis happy or just as a copycats because some other compilers do that why not Fortran?) why not to make compiler to check a and b and in my case allow it go without any interfaces ? Sorry, i might sound dumb, because still for more than a month deciphering one code written as claimed in Fortran 2011 which is like a cryptomachine causing my brain damage Smile. It outputs data in proprietary format SILO for which there is no file converters or viewers for its structure (i can see its visualization content in third part graphics software though, but this is not enough for futher use of code output)
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed Aug 24, 2022 8:36 am    Post subject: Reply with quote

Dan

Optional and named/keyword arguments were introduced at the "beginning" i.e. in the Fortran 90 standard.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Aug 24, 2022 3:39 pm    Post subject: Reply with quote

Hi Paul,

For some of us, Fortran 90 was more like the end than the beginning ...

Eddie
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Wed Aug 24, 2022 4:36 pm    Post subject: Re: Reply with quote

PaulLaidler wrote:
Dan

Optional and named/keyword arguments were introduced at the "beginning" i.e. in the Fortran 90 standard.
and they do require an interface definition, either explicitly or via contains, as Ken has outlined.

A lot happened to F95 after F90 !

it is not "call sub ( a==b )" which would be a different spin,
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Wed Aug 24, 2022 6:24 pm    Post subject: Reply with quote

Paul,
Seems no one since 1990th used such a=b option and those who used did not ask the question why interface was needed when it is clear that sometimes it is not needed. Was interface required because Fortran compilers back then did not check subroutine arguments for consistency?

Great that Clearwin functions do not require interfaces, that would be a disaster

Eddie,
And there also exist linked lists also introduced hell lot ago which will crush not only the human brains but also the brains and cache coherency of pipelines of all predictive branches of processors https://en.wikipedia.org/wiki/Linked_list

John,
The question is why they need interface definition? I gave definition for a and b enough for Fortran to run the code unambiguously.
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Wed Aug 24, 2022 9:10 pm    Post subject: Reply with quote

Dan,
Code:
b=1
a=b
call sub1(a)

Is not the same as
Code:
b=1
call sub1(a=b)

as in the second case (a=b) is not an assignment in the "usual" way. It is showing that argument A is present with value B.

Example:
Code:
Program test
implicit none
real b              ! No need to define a as real
b=1
call sub1 (a=b)
call sub1

contains

  subroutine sub1(a)
  real, optional :: a
  if (present(a))        print*,a
  if ( .not. present(a)) print*, 'no a input'
  end subroutine

end program


But the program runs OK, if you omit the optional declaration for A in SUB1 and don't use the PRESENT inquiry function.
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Wed Aug 24, 2022 9:32 pm    Post subject: Reply with quote

Ken,
As valid by common sense code my example should work. I think it does not work just because possibly not all options were taken into account by FTN95 - no one in 20 years used this super rare twist besides geeks of 80th level, those who were paid by the number of lines of source code adding millions interfaces or those who wanted to make their codes unreadable to 99% fortraneers Smile. I am not insisting to fix this as it looks like there is no any benefits for the codes with this (currently) cryptic syntax.

Or may be writing variables like this
Code:
call sub1(a=b)
is a good idea and will save us one line of code if it will not require any interfaces/modules/anything and will work like in my demo example which currently does not work.

But something related to better checking of arguments of subroutines still needs a fix as this code prints the result 6.6e-37 while has to write "no a input"

Code:
Program test

call sub1

end program
!----------------------
  subroutine sub1(a)
  real, optional :: a
  if (present(a))        print*,a
  if ( .not. present(a)) print*, 'no a input'
  end subroutine


Definitely by not working and requiring interface (or as you have shown by placing into the module or into CONTAINS) my demo example will confuse the programmer who will not understand why with interface or in module it worked and without did not.

If there will be more detailed error message explaining that the Standard by unknown reasons always requires interface or be in the module for such cases even if all variables are available and declared - hell knows why - then this might help not to lose time trying to find the ends.

Last 6 months i was literally losing time trying to get through similar twists of "modern" Fortran and so far did not find any rationale for using most of them. More and more i find they are more bad than good for the code readabilty, maintenance and speed.
Back to top
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Thu Aug 25, 2022 9:00 am    Post subject: Reply with quote

Dan, That's an interesting twist to my last example. Another compiler does issue an ERROR at the call to sub1, "Explicit interface required for 'sub1': optional argument.

FTN95 with Checkmate does generate a run-time message "Attempt to call a routine with zero arguments when one is required". Which I agree does not help to pinpoint the need for an explicit interface.

One for the folks at Silverfrost to consider at some point.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Aug 25, 2022 10:32 am    Post subject: Reply with quote

gFortran does do better in this respect in that it generates a compile time error.

However, sub1 and the sub-program that calls it could be in separate files. In which case the caller knows nothing about the arguments at compile time and the compiler is unable to do any argument checking.

FTN95 deals with this via the runtime checking of CHECKMATE which may be unique.

As a general rule, sub-programs are separately compiled. If they reside in the same file then the compiler may do some cross referencing and indeed FTN95 does do this in most contexts but apparently not in this case.

For separate compilation and in the absence of an interface, the best that a compiler can do is to check that different calls to a sub-program are consistent in the number and in the type of the arguments.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Aug 26, 2022 2:30 am    Post subject: Reply with quote

Paul,
The gfortran gave diagnostics
Code:
    4 | call sub1

      |         1

Error: Explicit interface required for ‘sub1’ at (1): optional argument


exactly opposite to what i claim. It just formally follows the Standard which for safety always (as if there were two separate files while there were actually single file with two programs enough to think a bit further) requires interface but my point was that in some cases interface is not needed and smart compiler can deal with this rising its artificial intelligence to the next level and resolving the problem by itself. Smart compiler will be more verbose and will issues just the warning where tell the user all these suggestions Ken have shown above (place arguments in the MODULE or CONTAIN) for the user to be aware and decide what's to do. For my demo example where all a and b were defined it also should just issue a warning and go without a bug.

The FTN95 was as always smarter but just had a bug which needs fixing. Compared to FTN95 the gFortran just got more 2003/2008 features and has little bit better C integration and Intel Fortran compatibility (plus it supports OpenMP and MPI and could be sometimes faster) but as a bug crusher it is a disaster. It can sometimes swallow without hiccups such horrible mistakes in the source code that you can not believe. I will find such examples when time permits
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Aug 26, 2022 6:47 am    Post subject: Reply with quote

Dan

I don't understand what you are saying.

1) Interfaces were introduced in Fortran 90.
2) Fortran compilers support Fortran 77.
3) For some features of Fortran 90, compilation requires an interface and both logic and the Standard naturally insist on this.

The sample program illustrates a case where FTN95 could give useful feedback but the bug is in the code not in the compiler. FTN95 is usually what you call "smart" in situations like this but (at the moment) not in this particular case.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10  Next
Page 7 of 10

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group