More Fortran 2003 and 2008 features

I notice that Paul requested us on Dec 05, 2022 to stop posting more suggestions to the 'Fortran 2003 and 2008 features' topic https://forums.silverfrost.com/Forum/Topic/3079&start=135. So here is starting a new one!

Could we get the 2008 Block structure implemented?

Many thanks

Simon

I will add it to the list but it looks like it could be a major task.

Paul,

A new list inevitably generates new requests.

The additional protection provided to module variables by the PROTECTED attribute would be a useful addition, to prevent inadvertent changes (i.e. programmer error) to calculated module constants which for some reason are not protected by virtue of being PARAMETERS.

module p_mod
implicit none
private
public casper, j, init
integer             :: casper   ! Value of CASPER can be changed external to the module
                                ! It could not be changed if FTN95 supported the PROTECTED 
                                ! attribute, 
                                ! i.e. INTEGER, PROTECTED :: CASPER
                                 
integer, parameter  :: j = 1    ! Value of j cannot be changed since it's a parameter, so it's
                                ! already protected.

contains

  subroutine init               ! Value of CASPER could be too complex to define as a 
    casper = 1                  ! parameter in an initialisation.  Value of CASPER can only
  end subroutine init           ! be changed within the module if PROTECTED.
  
end module p_mod

program main
use p_mod, only : casper, j, init
call init
print*, casper
casper = casper + 1     ! This change to CASPER'S Constant would not be allowed if FTN95 supported PROTECTED
print*, casper
print*, j
!   j = j + 1           ! This change to J is not allowed since J is a parameter
print*, j
end program main

(Casper is a Jack Russell Terrier, who is never happy when I’m in coding mode, and has introduced a few coding errors pawing my laptop keyboard!)

Thanks Ken. I will make a note of your suggestion.

The PROTECTED attribute has now been added for the next release of FTN95.

As an aside, it is interesting to see how some additions are relatively simple whilst others, though apparently simple, turn out to require a major investment of resources.

For example, the addition of PROTECTED only required a couple of man days to complete whilst the addition of 'Parameterised derived types' required a number of man weeks.

Looking ahead to the possible addition of the BLOCK construct, much of the work would be routine because it would be a matter of copying what already exists for constructs that in many ways are similar. But the difficult part will be the scoping of variables that are local a BLOCK. That concept is part of the core design of a C compiler like SCC but is not currently built into FTN95.

Thanks Paul,

I do sometimes think that the level of support received from Silverfrost is higher than the annual maintenance cost for a single licence for FTN95. “Active” users (i.e. those looking for enhancements to the Silverfrost product) receive excellent, professional and responsive support – all at a very reasonable price.

Excellent work, well done.

Paul, if the BLOCK structure is a lot of work, it is not a high priority for me. I'll use it if it's there, but I am not feeling much constrained without it.

I tied myself in knots today using MAXLOC not realising that the same maximum value was appearing multiple times in an array, so I wonder if the Keywork 'Back' can be added to the wish list for functions such MINLOC, MAXLOC, and FINDLOC, to detect when this happens?

program p
implicit none
real*8:: a(1:10) =[1,2,10,1,10,8,7,10,8,7]
print*, minloc(a)                   ! Returns 1
print*, maxloc(a)                   ! Returns 3
print*, findloc(a,8.d0)             ! Returns 6
print*, minloc(a,BACK=.TRUE.)       ! Would return 4
print*, maxloc(a,BACK=.TRUE.)       ! Would return 8
print*, findloc(a,8.d0,BACK=.TRUE.) ! Would return 9
end program p

Ken: I will add this to the wish list.

Simon: The BLOCK structure has now been added for the next release of FTN95.

The existing Win32 and x64 FTN95 intrinsics MINLOC, MAXLOC and FINDLOC have now been extended to allow the BACK argument. The implementation will be in the next release of FTN95 and also requires new DLLs.

Paul, thanks for taking the time to implement 'back' for these three intrinsics. This will be very useful for future programs.