Hello all and thanks for the lively discussion of present & future Fortran.
This is my first post. I am a scientist at an atmospheric sciences lab (LMD/IPSL in France) involved in the present and future of our climate modelling software, which represent a large codebase of not-so-modern Fortran. I am concerned with the viability of Fortran for our work, and at the same time willing to advocate at my institution for more involvement in Fortran tooling and Fortran features.
I have looked with interest at the proposed generic features for Fortran. It seems very well thought-out with a lot of potential, thanks for the great work. For my own education I sketched a generic implementation of a Runge-Kutta time stepping scheme and tried compiling with lfortran. However I get :
“semantic error: Only functions can be instantiated”
In the current proposal, is it possible to define a derived type in a template, and then use it in a subroutine using or instantiating the template ? I think I have seen such examples in the Discourse, but unfortunately cannot find them anymore.
Thanks,
Thomas
module template_add_m
requirement R(T)
type :: T; end type
end requirement
template try_t(T)
requires R(T)
type my_type_t
type(T):: x
end type
end template
contains
subroutine test_template()
instantiate try_t(real), only: my_type_t
end subroutine
end module
This is a separate issue regarding the ability to write generic functions.
There are several fortran intrinsic functions where the programmer can specify the returned kind with an argument: REAL(X,KIND=RK), INT(X,KIND=IK), SIZE(X,KIND=IK), and so on. There are several of these functions that work like this because it is obviously a useful feature.
However, it is not possible for a programmer to write a function that works this way. When designing and writing generic functions, it seems like this would be a good feature for programmers to have too. Is there any way that this feature could be included along with, or within, the ongoing generic template proposal?
The general idea is that when the compiler sees F(X,KIND=RK), then it would check to see if it has already compiled the template F() with that particular argument combination, and if not, then it would compile it at that time, and then establish the appropriate reference and the argument association.
If I understand the present proposal correctly, then the code should be:
module template_add_m
!public :: test_template
template try_t(T)
type, deferred :: T
!public :: my_type_t
type my_type_t
type(T):: x
end type
end template
contains
subroutine test_template()
instantiate try_t(real), only: my_type_t
end subroutine
end module
Thanks @AniruddhaDas . I tried your changes in the online lfortran and get the same error message.
The error is thrown from here
So it seems it is indeed forbidden in the present prototype. But maybe planned as a future feature ? It seems an essential feature to make templates fully usable.
This would be a valid template under the current proposal (although the public statements are unnecessary as written). LFortran is still just doing some early prototyping (albeit greatly appreciated), so unimplemented features and bugs are expected at this stage.
@dubos if you want to help with the LFortran implementation (I noticed you figured out where the error message is coming from), we would really appreciate it! The more hands on this, the better.
You can help by reporting bugs as well as sending PRs. I can help with answering any questions and help getting you up to speed.
Nice. The truth is, as soon as you taste the existing features, you wish you already had the missing ones. My skills will stop at bug reports, but I will ask a colleagues with compiler skills if he can spend some time on lfortran.
Beyond bugs I will be happy to contribute examples using template features such as the RK scheme that I had initially in mind.
If I have remarks on the proposed features for 202Y, is this discourse the appropriate channel ?
This forum is a good channel. Some of the committee members (myself included) frequent this forum, and many of us like it for the purposes of having open/public discussions with the broader community.
When programmer uses a preprocessor to generate fortran code from a template, the output source code is available for inspection, and after it is compiled, it can be debugged in the usual ways (interactively, or with print statements, etc.).
Does the proposed fortran template facility allow any way to inspect and debug the output code (i.e. after all deferred types and operators have been expanded)?
Perfect! Yes, bug reports are great. Both for valid code that should compile but doesn’t, and for invalid code that shouldn’t compile but does (or the error message should be improved).
If I have remarks on the proposed features for 202Y.
The last ISO-IEC/SC22/WG5 meeting that a French delegation attended was the one they hosted at Chateau de Cadarache in 1999.
(And the last meeting that a Finnish delegation attended was the one they hosted in Oulu in 2000.)
Even better than the Fortran discourse forum would be to re-form a French delegation (and a Finnish one) and resume participation in standard development and maintenance.
