to disseminate information about Fortran and its application in various fields,
to provide a platform for discussion of users’ needs and requirements in future versions of Fortran,
to encourage the development of the language in collaboration with national and international standardization bodies,
to promote the use of the Fortran language.
The committee is comprised of academic and commercial programmers, past and present WG5 members, representatives from compiler companies and also experienced educators, amongst others.
Members have normally been BCS members but we have accepted non-BCS members subject to conditions imposed by BCS. If you would like to join BCS you can use the code BCSFORT20 to get a 20% discount if you join online. Anyone can attend our meetings - you don’t have to be a member of the Fortran SG or BCS.
If you just want to hear about activities of the group, we can commit to sending announcements here, if that is acceptable. This is very low traffic and normally relates to one event a year. We are always on the look out for speakers for our annual talks - this year it will be in the afternoon of 29th September in London.
Sorry for the delay in responding - I don’t use this platform very often.
Anyone can join the BCS - there are no nationality or residence requirements. If you do join the BCS please use the discount code BCSFORT20 to get a 20% discount. This also helps the Fortran SG from a internal kudos perspective.
Given that all our meetings (aside from the AGM) are open to the public, Fortran SG membership is really just a subscription to an announcement mailing list.
You can register for the joint IoP/BCS Conference (online or in-person) using this link (it’s free!):
During the afternoon conference I will be giving an overview of Fortran-Lang and its projects, and a demonstration of fpm/stdlib. (The presentation is based on the State of Fortran presentation given during last FortranCon).
Are there any other uses for the array index operator @[...] besides those shown in the The new features of Fortran 2023 PDF (slide 16)?
Every example shows to the right how it is done currently, simply using the semicolon, which is shorter (fewer characters to type, even more so considering in many keyboards @, [ and ] probably require holding Shift or AltGr).
And the new enumeratoion type, does it not allow to specify the value of each enumerator (as the enum, bind(C) example shows?
Having the ability to specify the type and kind of the enumerator and its value was a strong use case for me and the peers in the domains of interest to me.
I tried very, very hard to convince the designer of the feature in Fortran 2023 but I failed. If the enumeration type were to be restricted to integral enumerators only in Fortran and that is all the implementors could manage (C++ is like so), then at least the ability to specify the kind and value was a compromise I sought but I failed with that too. So 1980s Pascal style enumeration type is all the designer would pursue for Fortran 2023 and all the voting members on the committee went along with that which I think it is handing out a far inferior product in year 2023 for the practitioners in actual practice.
Fortran practitioners can hope the value with the Fortran 2023 facility toward array notation using multiple subscripts or subscript triplets is with the use of rank-one arrays programmatically during run-time to work with array sections and elements.
This Fortran 2023 improvement can then help get over the hurdles with the current standard around sticking with constant expressions e.g., Fortran 2023 will permit
..
real(WP) :: a ( .. , .. ) !<- some rank-2 array
real(WP), allocatable :: b(:,:)
..
b = a(@v1:v2:v3) ! this can be the same as b = a( 3:9:2, 5:10:3 ) assuming
! v1, v2, and v3 are rank-1 arrays with the same size as rank(a) and
! the values of these 3 rank-1 arrays are presently
! v1 = [ 3, 5 ], v2 = [ 9, 10 ], v3 = [ 2, 3 ]
The issue I see with that notation is that it hides the rank of the array. If one is not familiar with the code, a(@v1:v2:v3) doesn’t tell you whether it is a(:,:), a(:,:,:) or something else. You have to go back and check the definition of a or v.
But in essence, that’s the point. The plan is for eventually things like this work.
subroutine foo(x)
integer, intent(inout) :: x(..) ! assumed rank
...
! This is purely speculative and hypothetical at this point
! But the intent is to loop over each element in x
do concurrent (i = @lbound(x) : @ubound(x))
...
x(@i) = ...
end do
Where even the declaration of x does not tell you its rank.
Could you go into a little more detail for this example? How would one write expressions on the rhs of that statement that depend on the value of array i(..) which has assumed rank?
i is would not be assumed rank, but assumed/automatic shape (we haven’t begun to discuss how exactly to declare it). It would be a 1-D array with size equal to the rank of x. But you could do something a little goofy like:
subroutine foo(x)
integer, intent(out) :: x(..) ! assumed rank
! This is purely speculative and hypothetical at this point
! But the intent is to loop over each element in x
do concurrent (i = @lbound(x) : @ubound(x))
x(@i) = sum(i)
end do
end subroutine
Ah yes, you are right, I was thinking of it wrong. Your explanation makes it clear. It is more like an allocatable array i(:) whose size depends on the rank of the array that is being indexed. I can see how the indices could be extracted from i(:) within the loop.
