search

j3-fortran / fortran_proposals

Proposals for the Fortran Standard Committee
178 stars 15 forks source link

Proposals for February 24 - 28, 2020 J3 committee meeting #122

Open certik opened 4 years ago

certik commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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. 104

  2. 36

  3. 86

  4. 1

  5. 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 commented 4 years ago

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

certik commented 4 years ago

@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 commented 4 years ago

@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 https://github.com/j3-fortran/fortran_proposals/issues/46#issuecomment-546722675 and https://github.com/j3-fortran/fortran_proposals/issues/46#issuecomment-546979885 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 commented 4 years ago

@FortranFan thanks for sharing the concerns. As @sblionel mentioned in https://github.com/j3-fortran/fortran_proposals/issues/98#issuecomment-559901826, 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 commented 4 years ago

Here is my list:

  1. 4

  2. 16

  3. 36

  4. 1

  5. 102

I could also add #22 and #104

cmacmackin commented 4 years ago

My votes:

  1. 4 (or one of the other similar issues)

  2. 27 (although this was recently rejected by the committee, without good reason in my view)

  3. 1

  4. 28

  5. 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 commented 4 years ago

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 commented 4 years ago

  1. 4

  2. 125

  3. 27 - Combined with #4 and #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. 16 - I would use this tomorrow. I've exposed some attributes as public explicitly for performance reasons, and this would make that safer.

  5. 36 - 5 years is absolutely too long to wait between releases

klausler commented 4 years ago

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 commented 4 years ago

  1. 36 - 3 years, even if only temporarily, will help Fortran catch up to community concerns

  2. 4 - Templating, or some alternative, is needed to eliminate a lot of boilerplate code around types

  3. 1 / #87 - More namespace controls would eliminate the "flat" namespace

  4. 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. 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 commented 4 years ago

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

  1. 4 (templates)

  2. 1 (namespaces)

  3. 13 (real16)

  4. 22 (default value for optional)

  5. 104 (stdlib)

ivan-pi commented 4 years ago

My top picks at the moment are:

  1. 119 overloading ()

  2. 16 protected attribute

  3. 1 namespace for modules

  4. 76 variadic functions

  5. 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 commented 4 years ago

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

  1. 24 string intrinsic type

  2. 4 templates

  3. 22 default value for optional dummy args

  4. 61 deallocate/reallocate option for allocate

  5. 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 commented 4 years ago

My priorities:

  1. 1 and #87: Namespaces and nested namespaces

  2. 16: Protected variables in derived types

  3. 61: Reallocation

  4. 76: Variadic functions.

  5. 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 commented 4 years ago

Here are my priorities:

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 commented 4 years ago

Here are mine:

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

arjenmarkus commented 4 years ago

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:

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 commented 4 years ago

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

reinh-bader commented 4 years ago

Given recent (personally communicated) comments from one of the https://github.com/fortran-lang/stdlib developers, I've added https://github.com/j3-fortran/fortran_proposals/issues/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 commented 4 years ago

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 commented 4 years ago

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