We had several votes yesterday. If I am not mistaken, we have selected either the “keyword” or the “arrow form” as the two alternatives going forward. We will be tweaking the syntax on Wednesday. It looks like using (a ? b : c) instead of the arrow has a lot of support.
Somebody asked if we should also vote to not add this feature in the first place, which is what I would personally prefer. But this was rejected, so we did not vote on that. Also it looks like most people want conditional expressions (in some form). Since we did not have the vote at the committee, let’s vote here. Do you want us at the committee to:
Add conditional expressions to Fortran 202X (assuming we come up with syntax that you like)
Do not add conditional expressions to Fortran 202X
Here’s my recollection of the relevant votes (all straw votes):
Choose the syntax that you like, multiple choice, options were keyword/concise(????)/arrow/function/undecided. Result: 15/6/15/10/1.
The three “concise” forms (????, arrow form, and C-syntax as alternative to arrow but using the ? symbol) were then consolidated into one as “concise”, to attempt to weed out between keyword and concise. This was a single choice vote, options were keyword/concise/function/undecided. Result: 13/13/2/0.
To attempt to resolve the tie from #2, there was now a straw vote that asked which form was unacceptable, keyword or concise. The was a single choice vote, options were keyword/concise/undecided. I didn’t write down the outcome, but there were more votes for the keyword syntax being unacceptable over the concise.
Somewhere in there was also a straw vote whether the C-syntax (a ? b : c) is preferred over the arrow syntax (a -> b : c) and I believe the outcome was higher preference for the C-syntax.
Btw, and if only variables are used (such as yours (predicate => then-var : else-var)), then that can be implemented already as ifthen, the implementation is here:
No. Malcolm wrote the proposal for keyword and ????, Bob for the -> and I for ifthen. Nobody else submitted any other proposal, so that was what we had to choose from.
Wouldn’t that get very confusing given that an extra () around the construct would produce an expression and () is part of the syntax of the construct?
So I am a bit confused here. As a user I would like to know why the committee chose the arrow (->) form? It’s not the majority of the votes, not even the second most popular choice. I mean I understand that the final decision does not come directly from the poll, but I would like to know the reason behind that decision.
If I ever want to demonstrate my code to some of the professors who only know FORTRAN77 and a bit of Fortran90+ (which is fine and I don’t blame them for this), I either have to use the old style or add more comments to explain that “this is equivalent to blah blah blah”. If I ever want to teach some of the younger students Fortran202x, I will have one more style to teach them. Thus I can’t foresee the benifits of this new feature.
A single feature update is not a big deal, and personally I am totally fine with the change because I use similar expressions in C and gnuplot all the time. However, I am seeing a trend. This is the feeling I have when I started learning Julia a year ago: “to do X, you have option a/b/c/d/e/f, wait, there is an option g to accomplish X as well!”. Then I will have to figure out which ones are just syntactic sugars and which ones are performance decisive… no don’t go there Fortran!
If I have understood @certik and @Beliavsky messages, the committee did not choose the arrow form, but a ? form, very similar to the C syntax, which seems a wise decision.
Yes, you are correct, and in the file @certik attached the suggested example is
y = ( i>=1 .And. i<=Size(a) ? a(i) : -Huge(y) )
Personally if I see a line of Fortran code like this I would have a strong tendency to change that .and. into &&. It’s definitely not C, and it’s not Fortran either. Something is just not right! (Bear with my OCD, lol).
I am with you, I don’t think we should be adding features like these and I suggested not to do this feature at the committee. But others disagree and I am in the minority. I even created this little poll:
and as you can see, majority wants this in (yes, it’s only 14 people so far, so not representative yet — but I expect this stay even if 100 people or more vote).
Now, I use C++ often, and I ask people who use the ? notation to please rewrite using if in PRs. So even though C++ has this feature, we don’t use it in the projects that I maintain.
If there is a huge push back, say 80% of people in the above poll vote against adding conditional expressions, then we can always submit a paper to take it out at the next meeting. But unless I see that (and I don’t currently), I am going to agree to disagree with the majority and move on. We’ll have the ? conditional expressions in Fortran.
I see this type of comment often when Fortran is mentioned, and it puzzles me. What are computers for? Mainly for games and websites, with scientific computation an obscure niche? I don’t think so. Computers are for modeling the climate, predicting the weather, simulating the economy, calculating the merger of galaxies, and designing airplanes. For any of these, the high-performing languages are Fortran, Julia, C, and C++. That’s it. Lisp, Erlang, and Smalltalk are wonderful languages, but not for this.
I vote for the keyword form because we are used to if … then … elseif … then … endif but I am not sure whether elseif and else if are both allowed, similarly endif and end if. As an old Algol user I like the proposal.
)