Proposals for February 24 - 28, 2020 J3 committee meeting

[certik]

Here are the submitted documents: https://j3-fortran.org/doc/meeting/221.

Let's use this issue to help coordinate and prioritize proposals for the next J3 meeting 221 in February 24-28, 2020.

Everybody, can you please ensure you put thumbs up on issues that you find high priority, and then help us create high quality proposals for this meeting by submitting PRs against this repository. Once a proposal is ready in this repository, I am happy to submit it officially so that it appears at https://j3-fortran.org/doc/meeting/221.

What do you think should be the top 3 to 5 issues that we should concentrate on? Go ahead and comment below with your personal top 3 to 5 issues. Let's see if we can agree on some of those as a community. Then let's ensure we have good proposals for those. Beyond those, if you feel strongly about some feature, go ahead and start drafting a proposal and motivate in there why it is a good feature.

[certik]

Here is the current list of issues sorted by the number of thumbs up, which we can use as an (imperfect) hint of which issues might be popular.

[klausler]

I suggest that the proposals can be triaged into three tiers: (1) fixes to actual bugs in the language, (2) features that enable new usages that are impossible or impractical today, and (3) conveniences.

[certik]

I'll go first. Here is my list (I will update it and/or re-order if I get convinced based on a discussion):

1. Standard library proposals #104

2. Consider releasing Fortran standard every 3 years instead of 5 #36

3. Allow modules to be nested like in Python #86

4. Namespace for modules #1

5. Matrix literals #102

Comments: Number 1. might not need a formal proposal, but it's something I want to informally discuss with every committee member and try to get their support. For me this is the highest priority, and actually something we can achieve as a community today, with today's compilers. This would be a huge quality of life improvement and big productivity boost for any Fortran developer. The number 2. also is more of an issue to get support at the committee for. The numbers 3., 4. and 5. would require proposals.

I will also try to write proposals for #81, and #40. Especially #40 would be a nice quality of life improvement.

[certik]

@klausler great idea, I made this a new issue #123, so that we can discuss the details and make that happen.

[certik]

@FortranFan, @milancurcic, @jacobwilliams, @jvdp1, @zjibben, @marshallward, @zbeekman, @everythingfunctional, @qolin1, @rweed, @gronki, @ivan-pi, @aradi, @arjenmarkus, @cmacmackin, @Beliavsky, @pbrady

The next J3 meeting is less than 2 months away. We brainstormed a lot of ideas, but now it's time to turn some of the ideas into action and create a few high quality proposals. Please comment here with your top five priorities for this next meeting. Hopefully there will be some overlap, and then let's work on the issues/proposals of common interest.

(I tried to tag everybody who created issues here, feel free to forward this issue to others.)

[FortranFan]

@certik wrote:

..
The next J3 meeting is less than 2 months away. We brainstormed a lot of ideas, but now it's time to turn some of the ideas into action and create a few high quality proposals. Please comment here with your top five priorities for this next meeting. Hopefully there will be some overlap, and then let's work on the issues/proposals of common interest.
..

@certik , thank you very much for your initiative.

My concern is the posted agenda for the meeting (https://j3-fortran.org/doc/year/20/agenda221.txt) that appears essentially a carbon copy of the last N number of meetings and which effectively only allocates time ("officially at least") for Fortran 202X items.

But now, not only is the work-list for Fortran 202X fixed to that set by the Tokyo meeting last summer as noted at this link https://isotc.iso.org/livelink/livelink?func=ll&objId=20646091&objAction=Open, but even the feature specifications also appear locked in place based on discussion and votes at the Tokyo meeting.

There seems to be no room to maneuver on any 202X items even e.g., with US-21 on "typed enums" vis-a-vis #46 (comment) and #46 (comment) other than to wait for years when the next window of opportunity opens up for any improvements to features implemented in an earlier revision.

How do you see any proposal fit into this scheme? Thanks,

[certik]

@FortranFan thanks for sharing the concerns. As @sblionel mentioned in #98 (comment), the committee will consider every proposal submitted to it. His word is good enough for me. As you know, it will take some time and iterations and several committee reviews for every new proposal / idea that we submit in order to get in. So let's get started. Once we have proposals that have been positively reviewed by the committee, and are rock solid, and backed by the community, then let's convince the committee to put it into the standard sooner than in 10 years (i.e., to fix #36). But we need those proposals first, so let's work on that, and once they are ready or near ready, let's have a discussion at the committee how to fix #36.

[jvdp1]

Here is my list:

1. Templates for functions/subroutines #4
2. Protected attribute for variables in derived types #16
3. Consider releasing Fortran standard every 3 years instead of 5 #36
4. Namespace for modules #1
5. Matrix literals #102

I could also add #22 and #104

[cmacmackin]

My votes:

1. Templates for functions/subroutines #4 (or one of the other similar issues)
2. Remove restrictions on proc-component-ref #27 (although this was recently rejected by the committee, without good reason in my view)
3. Namespace for modules #1
4. Allow derived type components to have target attribute #28
5. Overloading () #119

Personally I'd like to see #30 taken forward, but not too many people agreed with me that this was important. Obviously #36 would also be very helpful.

[rweed]

My list would be:
#1 - recently encountered a case where this would be useful
#4/29 - anything that gets us closer to better generics even if its not what everyone wants
#61 - my proposal so I have to support it. I think its of immediate use and would be trivial for the developers to implement so it might have a chance of gaining traction with the committee
#65 - if we can't have intrinsic generics/templates a standardized pre-processor that makes generating different versions of the same code easier is the next best thing
#70 - a standard assert routine would be very useful as a first step to better error handleing. Also something that looks like it would be straight forward to implement.
#40/90 - I would at least like some language in the standard that encourages developers to make explicit typeing the default mode and force people who want to stick with implicit typing use a compiler flag (opposite to the current mode in many compilers) to make it the default. Again, I see this as more of a policy problem than a technical one. It just takes a vendor/developer to summon the courage to change the default mode.

I also support the items currently on the J3 F202y list (ie coroutines etc.)

[everythingfunctional]

1. Templates for functions/subroutines #4
2. Traits For Types #125
3. Remove restrictions on proc-component-ref #27 - Combined with Templates for functions/subroutines #4 and Traits For Types #125, this would make Fortran's capabilities on par with practically every other language. Even if some techniques or patterns would be cumbersome without some additional work, they would at least be possible.
4. Protected attribute for variables in derived types #16 - I would use this tomorrow. I've exposed some attributes as public explicitly for performance reasons, and this would make that safer.
5. Consider releasing Fortran standard every 3 years instead of 5 #36 - 5 years is absolutely too long to wait between releases

[klausler]

If we had some form of parameterized modules, plus modules-as-namespaces, we could have something as powerful as subprogram templates but more general and flexible. E.g., CALL SORTING_MODULE(MY_TYPE)%SORT_LIST(MY_LIST). I encourage you to seek the most general and powerful features, and to do so in combination. Also, please don't forget about fixing bugs.

[marshallward]

1. Consider releasing Fortran standard every 3 years instead of 5 #36 - 3 years, even if only temporarily, will help Fortran catch up to community concerns
2. Templates for functions/subroutines #4 - Templating, or some alternative, is needed to eliminate a lot of boilerplate code around types
3. Namespace for modules #1 / Namespaces #87 - More namespace controls would eliminate the "flat" namespace
4. Standard library proposals #104 - As mentioned, perhaps this need not be a proposal, but some recognition of a stdlib would at least allow for a safe deferral of features
5. Namelist delimiter proposal #94 - My "pet" issue. But since it addresses an error that the standard itself acknowledges, it is a good test to see if the committee is serious about resolving simple problems.

#36 and #104 are meta-proposals, which will help future development. #4 and #1 feel like very fundamental concepts needed for Fortran to evolve to modern expectations.

I'd also like for #22, #30, #40, #90 to be considered if possible, but not if they will cause friction.

[milancurcic]

Ondrej, thanks for leading this effort. My votes are:

1. Templates for functions/subroutines #4 (templates)
2. Namespace for modules #1 (namespaces)
3. REAL16 proposal #13 (real16)
4. Allow setting default value for optional dummy argument #22 (default value for optional)
5. Standard library proposals #104 (stdlib)

[ivan-pi]

My top picks at the moment are:

1. Overloading () #119 overloading ()
2. Protected attribute for variables in derived types #16 protected attribute
3. Namespace for modules #1 namespace for modules
4. Variadic functions #76 variadic functions
5. Automatic differentiation in Fortran #95 automatic differentiation

I have included number 5 because I created the issue and I think it has some of the most far reaching consequences with respect to the application of Fortran in the scientific and engineering domains, while the previous issues are mostly just programmer convenience. I also don't want Fortran to stay far behind Julia in this respect.

[epagone]

Given my limited programming proficiency, I'm not participating much but I'm following with great interest. FWIW, my preferences are:

1. Array of strings #24 string intrinsic type
2. Templates for functions/subroutines #4 templates
3. Allow setting default value for optional dummy argument #22 default value for optional dummy args
4. Add deallocate/reallocate option to ALLOCATE #61 deallocate/reallocate option for allocate
5. Deprecate and remove implicit save behavior #40 deprecate and remove implicit save

#50 (engineering units of measure) and #95 (automatic differentiation) did not make it in the top-5 but are very close.

Furthermore, I think #104 (standard library), #36 (release standard every 3 years), #56 (use lower case in the standard), #99 (extension to EXECUTE_COMMAND_LINE) and #106 (pathway to introduce straightforward features) are all non-technical proposals or (apparently) minor technical changes worth pursuing in my opinion.

[aradi]

My priorities:

1. Namespace for modules #1 and Namespaces #87: Namespaces and nested namespaces
2. Protected attribute for variables in derived types #16: Protected variables in derived types
3. Add deallocate/reallocate option to ALLOCATE #61: Reallocation
4. Variadic functions #76: Variadic functions.
5. Deprecate and remove implicit save behavior #40: Remove implicit save

I would love to see the generic programming being driven forward. A lot of ideas had been presented here, but I think, it needs more discussions, before any of them can be formulated as a formal proposal. But, if there were any to pick, I would go with the traits as in #125.

Finally as meta-proposal: #36 (3 years standard release cycle)

[zjibben]

Here are my priorities:

• Templates for functions/subroutines #4 templates
• Consider releasing Fortran standard every 3 years instead of 5 #36 shorter release cycles
• Standard library proposals #104 standard library
• Allow setting default value for optional dummy argument #22 default for optional values
• Namespace for modules #1 / Namespaces #87 namespacing and nesting

I also like #19, #40, and #113, which along with #22 I think make up a set of micro-scale issues which contribute to Fortran clunkiness. I’d also like to see #5 and #16 to help with data safety.

[qolin1]

Here are mine:

• Allow setting default value for optional dummy argument #22 default for optional values
• Deprecate and remove implicit save behavior #40 implicit save
• Eliminate implicit typing #90 implicit typing
• Namespace for modules #1 / Namespaces #87, namespace for modules
• Templates for functions/subroutines #4 Templating

Plus of course #124, #121 & #120, because none of them are at all difficult, and because I suggested them.

[arjenmarkus]

This was a tough one. I thought I might try to group the issues that seem to revolve around the same theme. Ordering rather arbitrary. Here is my list:

• Templates/generic features: Templates for functions/subroutines #4, Proposal for general-use templates #29, Generic Programming: modules parameterized over other modules #74 for instance, but also Traits For Types #125
• Exceptions: Better error handling #6, Use Cases for Exception Handling in Fortran #66
• Coroutines and iterators: Coroutines #60, foreach loop #116 (and perhaps Uniform syntax #53)
• File system access: File system and directory access #100
• Working with units: “Physical” or “Engineering” Units of Measure #50

Mind you: a large number of the issues may simply be implementable as a library (or libraries), so they contribute to the standard library proposal.

[pbrady]

Short circuiting: #19
Eliminating the need for septuply nested loops in 3D cartesian mesh codes: #85.

[reinh-bader]

Given recent (personally communicated) comments from one of the https://github.com/fortran-lang/stdlib developers, I've added #144
At least, technical feedback on this would be valuable. If positive, I would hand in an official German proposal on the WG5 level.

[certik]

Please keep sending Pull Requests (PRs) against this repository with your proposals based on the above priorities. I'll be happy to merge them and upload them to the J3 website. Here is the current list of uploaded proposals that the committee will consider: https://j3-fortran.org/doc/meeting/221

I will soon start a separate issue to track all those.

[certik]

The summary of the February meeting is available at #155.