I am also in favour of this because it significantly hinders the development of Fortran tools. I would as much as advocate that modifier keywords should be reserved by the standard, although I very well understand the nightmare this would unleash.
Here are my main grievances with non-reserved keywords
1. Syntax highlighting
Syntax highlighting is commonly provided by Textmate files using Oniguruma Regular Expressions, in which one defines scopes that are used to match Fortran expressions. These scopes can then be included to one another to form the final syntax highlighting scope.
It is very important that the scopes’ regexs match only what they are intended and nothing else, poorly written regexs will result in never closing scopes, which depending on the case will lead to a complete failure of the syntax highlighting for the entire Fortran source code.
Moreover, these regexs are static and hence cannot be modified by the extension at launch. Moreover, modifying the syntax files will affect the syntax highlighting of all Fortran code across all projects.
So why is that an issue?
Imagine you have the following code
! Normal function
function fun( arg )
integer, intent(inout) :: arg
end function fun
! Argument list and argument declaration are incorrectly highlighted
function fun_with_fun( function )
integer, intent(inout) :: function
end function fun_with_fun
! Argument list and argument declaration are incorrectly highlighted
subroutine sub_with_fun( function )
integer, intent(inout) :: function
end subroutine sub_with_fun
As you can see the argument function has been erroneously highlighted in the last two cases. It turns out you need to do 2 things to address this:
- while matching for a
function's/subroutine's definition, make sure that that definition is not part of an argument list i.e. surrounded by parenthesis.
- while matching your argument declarations make sure that
type, keywords, ... :: function never triggers the regex for the a Fortran function
In terms of regex both of these are doable with non-fixed width look-behinds, the only problem is that Oniguruma regex does not support that e.g. (?<!::[ ]*)). VS Code, Atom and probably more editors do not necessarily abide by the strict rules of Oniguruma, so realistically this could be implemented and has been part of Modern Fortran’s syntax highlighting solution since version 2.4.0. The only problem; non-fixed width look-behinds have terrible performance for large files and long lines to the point that they will cause your editor to crash, see issue 309 in Modern Fortran, to which currently I don’t have a solution.
All that is to say that if function, subroutine, etc. were reserved keywords none of these would be issues and writing syntax highlighting files for Fortran would become trivial.
2. Language Server implementations
Similarly to syntax highlighting a Language Server needs to parse Fortran code. Source code is parsed into an Abstract Syntax Tree (AST) which is then used to efficiently retrieve information for the original code e.g. the hover signature of a function.
To be able to handle cases like the code snippet above or like this example
program main
integer :: i
integer, allocatable :: sqrt(:)
allocate(sqrt(5))
do i = 1, 5
sqrt(i) = i**2
end do
print*, sqrt(sqrt) ! this is not the intrinsic sqrt, but an array indexing itself
end program
One has to code to extremely complex routines and/or write spaghetti code which not only is a pain to write but also a nightmare to maintain.
There are a few more issues like autocomplete result relevance, that would be resolved if Fortran used a larger set of reserved keywords, but I think the 2 points I raised cover most of my “complains”.