It’s again time to organise our next monthly call which will be in the week of August 16-20; please see the following doodle poll to mark your availability:
The final time slot will be selected and announced on the evening (European time) of Monday August 9, please complete the poll before then .
If there are specific topics or issues you would like to raise, even if you are unable to attend the call, please post them in the thread here.
As usual, we will record this call and make it available online.
Thanks, @jeremie.vandenplas. I won’t be able to join this meeting, nor provide the Zoom meeting room. Anyone else has a premium Zoom account to use? Otherwise, I found Google Meet to be a high-quality and free alternative, and has the features we use (screen sharing and recording).
I already opened threads for fpm and stdlib, where we can collect some ideas to refine further tomorrow at the call and continue the discussion afterwards:
1) Teams for fpm, stdlib, lfortran, twitter (social media team), etc. (@certik)
2) Process to suggest and discuss features for 202Y (@certik)
3) Open position at the ACM Fortran Forum (@arjen)
Details for the position at the ACM Fortran Forum see details here
@awvwgk@certik Unfortunately I will not be able to join the meeting due to a last minute personal obligation. Could one of you lead the meeting, please?
Regarding the 202Y standard, I think generics are the top priority. It is related to the development of the underlying libraries (one of the cornerstones of the Fortran ecosystem), including stdlib and fftpack.
After all, using fypp is a stopgap measure because of lacking generics, native support for generics is what I look forward to most for Fortran!
(see j3-fortran/generics (github.com))
Yes, generics are part of 202Y, even WG5 agrees to that.
How would generics help with fftpack though? Note that currently the fypp like usage is not part of the generics effort, but I would like to change that. So it is important to be specific when it comes to generics.
I assume what you are looking forward is to “generate” functions for any kind (single/double precision) and possibly also any type (integer, real), and also any rank (1D, 2D, 3D, …, arrays). Is that correct?
Yes, I hope that many implementations, such as the function sin, can be applied to arbitrary kind and type with only one template. It seems that kind(precision) is more important to me, after all, real(4/8/10/16) has four kinds of precisions, writing four copies of the sin function does not seem to conform to common sense. (or something like Function kind specified by optional input · Issue #91 · j3-fortran/fortran_proposals (github.com))
Isn’t this generic content?
About any rank, we have elemental label and will have dimension(..).
