If you are a J3 alternate, you’re automatically a WG5 member, as I wrote above. Furthermore, at the WG5 level, everyone is an “individual expert”, so you get to vote on WG5 things even as a J3 alternate.
You’re really asking if Fortran standardization needs to be under ISO. Theoretically, it doesn’t - there are other accepted standards organizations, including IEEE and OASIS OPEN. SImply ditching the organizations won’t work for a committee as small as Fortran as such a change would likely not be accepted by industry and government users. Still, there are discussions among the various SC22 (ISO Programming Languages) groups chafing under ISO’s bureaucracy. I’m skeptical anything will come of it, though.
I agree with @sblionel that it is very easy to join the committee and thanks to remote participation (which wasn’t the case before 2020) the participation itself is cheap too. However, from my perspective, the high bar of entry is the time it takes to attend and convincing my employer that they should pay me to work at the committee, or take a vacation (like @FortranFan used to do).
For me personally it works much better being able to discuss and create proposals over the year, few minutes here and there, rather than spending a week full time three times a year. That being said, spending in-person time is very valuable and effective.
All in all, if we are accommodating and understanding to each other, I think it can work.
My 2p: the short template procedure syntax looks really, really great, and pretty intuitive coming from other languages. I’m so much more excited for this than the longer template/instantiate syntax.
But using () for the template arguments is really… not good. Round-brackets will now have three separate and distinct uses (four, if you count the instantiation as a separate use). It’s bad enough that array indexing and function calls are syntactically indistinguishable. Please can we use some other punctuation? I really don’t see what the issue with {} is. From looking at the J3 documents, just as many people were in favour of option 2 as option 1.
Thanks Steve. I often forget about that aspect because it’s not obvious to the unfamiliar, and many of the members of the committee likely aren’t willing to add alternates that aren’t members of their organisation. A few are, and that’s enough, but it doesn’t make it obvious.
It’s also worth noting that frequently the personal cost to participation can be high. Many organisations aren’t willing to fund their employees to participate on the committee, let alone spend time contributing the Fortran’s development. That’s not a problem the committee can solve, but it’s worth acknowledging as a potential barrier.
It’s not really needed, but some on the committee thought it would be valuable to have some visual distinction in that specific case.
Because then it would be entirely superfluous in the case you weren’t calling the procedure too.
There is a hesitancy on the committee to “use up” more symbols if we don’t need to. I was in favor of {} as well, but the argument was that it’s not needed, and isn’t really all that visually distinct from () (especially for those with poor eyesight). There’s also something to be said that () are consistent with the rest of the language; lists of things are enclosed in (). There are much more than 3 or 4 of these if you start counting. I.e. dummy arguments, actual arguments, pdt parameters, type parameters, array indices, array dimensions, associate lists, case lists, and probably a few more I’m missing.
Yeah, I don’t think the use of ^ was worth it, but sometimes design by committee ends up with the least unacceptable, not the best.
Thats interesting. I haven’t read the J3 documents that close so I didn’t see that. I guess its a case of the committee functioning like the animals in George Orwell’s book Animal Farm. All committee members are equal but some members are more equal than others.
Yes, but fewer people were opposed to option A than option B. The part that I found odd was how many people were opposed to () everywhere, but not opposed when the ^ was added to the inline instantiate. FYI here is how it was presented to the committee and the results of the vote. (original here).
What symbol(s) should be used to delimit deferred and
instantiation argument lists?
A. Parenthesis with ^ added for inline instantiation: ^()
B. Curly Braces: {}
C. Square Brackets: []
D. Parenthesis: ()
E. Undecided
Examples:
A. 13-1-7 (acceptable-unacceptable-undecided)
subroutine swap(T)(a, b)
call swap^(T)(a, b)
call P1^(P2^(x))(a, b)
B. 13-5-4 (acceptable-unacceptable-undecided)
subroutine swap{T}(a, b)
call swap{T}(a, b)
call P1{P2{x}}(a, b)
C. 11-6-5 (acceptable-unacceptable-undecided)
subroutine swap[T](a, b)
call swap[T](a, b)
call P1[P2[x]](a, b)
D. 7-7-8 (acceptable-unacceptable-undecided)
subroutine swap(T)(a, b)
call swap(T)(a, b)
call P1(P2(x))(a, b)
Choice A was selected.
I propose an experiment on the committee’s real responsiveness to the user community at large by someone standing up a poll in a separate thread just on this syntax change. There should be a short explanation of what the issue is followed by a user poll. My money is on curly brackets.
Also, in this age where all major text editors support syntax highlighting/coloring for Fortran, I don’t think the readability issue is as big as some make out.
Edit: note my major objection to the ^ syntax is it looks (to me) like something a sixth-grader would come up with.
Not to be too rude or shoot the messenger or anything, but that surely is a matter of font choice. They are very distinct in basically every programming typeface. And if “visual distinctness” was a consideration, why choose identical symbols?
I’m not sure I really buy the “using up symbols” argument either, wouldn’t ^ be new too? I can’t see any uses of it in the F23 standard (also F23 added ? in ternary expressions, when it could’ve used x if a else y, reusing keywords!)
There was also no option for <>, visually distinct and already used.
This is true, but all of these cases are trivially distinguishable by both humans and very simple (i.e. regex-based) parsers (with the exception of array-indices and function calls). On the instantiation side, it will also be unmatched/asymmetric!
In the end, it’s not the worst thing in the world, but it is yet another clumsy piece of syntax.
I have always thought of this aspect of fortran syntax as a feature, not a bug. It makes it easy for the programmer to replace a function reference with an array lookup table, or visa versa, without also needing to change all of the parentheses to some other bracket form.
Regarding the ^ operator under discussion, exactly what is its purpose? Is it to tell the compiler that the referenced function needs to be compiled with the given combination of arguments? If so, then that seems like it places a large burden on the programmer, that is something that seems like the compiler itself should be figuring out.
Let’s change this. Let’s run a poll here (by explaining the issue, pros and cons, etc.), then write a paper and change it. If I understand you correctly that the committee wasn’t unanimous, then it means it wasn’t 100% convinced about ^() either.
The compiler/interpreter/processor knows that chars_result is not a parameterized derived type with overloaded operator(//), but it might not be obvious to the programmer without the ^.
I think it should originate from the community. I don’t think it would be proper for a committee member, who was in attendance at the meeting, to go off and complain about how they didn’t get their way as a method of trying to overturn some decision. But if there is a grassroots movement from people who weren’t in attendance and thus didn’t have a chance to get their opinion heard that would be grounds to re-litigate.
This is a fair point. I’m not sure it was mentioned in the discussion.
The use of these symbols would lead to ambiguous (or at least much more difficult to parse) cases, because they are also used in expressions. I.e. print *, tmpl_func < a, b > c, e < d, f > (e, f)
Correct. That was really the only argument in favor of adding it.
I think you didn’t mean it this way, but just in case I want to make sure: the purpose of the poll is not “to go off and complain about how they didn’t get their way as a method of trying to overturn some decision”. The purpose it so simply see what people think. So in my opinion it would actually be preferable coming from you, precisely because you were there, in the spirit of openness. But I am happy to do it too, I’ll try to do it soon. (Well, I am a committee member and was in attendance on Thursday morning, but this was done earlier.)
I agree that it’s a barrier., but… is the notion that one should be a “participant” in developing the standard without expending any actual effort? What’s the alternative? We already have the situation where a minority of the members do the work needed to specify and design changes and to come up with the wording changes to make it happen. If you look at the names of people who write J3 papers, the same ones come up over and over, and others are mostly or entirely absent. (Brad, you definitely put in the effort!)
I just don’t understand the complaints that participation is too difficult. Yes, standards creation and revision is hard work, and takes time. I had hopes that the “proposals” Github would encourage people to chip in and at least start the design work, but it feels to me as if it’s mostly a wish list, leaving the dirty work to someone else.
As for the ^, my understanding was that something was needed to avoid an ambiguity in the inline instantiation case, but I don’t recall the details. The use of parens otherwise was felt to be “more Fortranic”.
If I wasn’t restricted to mobile I would have made the thread after it was suggested @everythingfunctional@certik
I suspect the response will be better if the post is long winded with links to whatever discussions happened and everything, which is just history I don’t have.
It will be good to have an open discussion about it though. Honestly I’m somewhat surprised the idea of “design by committee” hasn’t already evolved to longer, open design and discussion periods followed by 3-6 month voting periods, all done in public spaces like this or GitHub. Development is slow regardless, so allow maximum participation for discussion, design, and voting by as many users as possible. I would strongly disagree with the notion that “programming language users don’t know what they want.”
I just don’t want there to be any question about the process and motivations here. If I were to be the one initiate the poll, there could be some appearance that I’m engaging in astroturfing. I.e.
In political science, it is defined as the process of seeking electoral victory or legislative relief for grievances by helping political actors find and mobilize a sympathetic public, and is designed to create the image of public consensus where there is none.
Any appearance of such action could (rightfully) be dismissed with the argument “your opinions were heard and considered and the committee voted. Trying to manufacture support for your position after the fact is misconduct and a waste of the committee’s valuable time.”
If somebody who wasn’t present at the meeting initiates the poll, that argument doesn’t work. Instead the argument is “the committee did not hear and consider the opinions of this important group and should reconsider their decision in light of new input.”
I take some blame for this, but I think we just haven’t communicated well enough what the options are for joining and how low that barrier to entry can be. Maybe it’s not that the barrier to entry is high, but just the perception is that the barrier to entry is high? Maybe we should have some more public (and well publicised) document/guide that outlines the steps for those interested in joining? Anything we can do to encourage more participation would be good.
Even without formally joining, some documentation about how to contribute would be helpful. There is some good start on the proposal github, but it’s limited: I have made a (minor) proposal that has apparently passed, but although I agreed to do a part of the coming work, I must say that I have no clear idea about what this work consists of …
@everythingfunctional Ok, I can see your point of view. I think it would be ok if you voted for ^(), but since you were for {}, it might be better if somebody else does it. I’ll do it. Thanks for the pointers in the other thread.
This astroturfing issue you mention is real. In the past when I was physically sitting at the committee and creating such polls, it does feel a little bit like “playing for both sides”. But opening up the committee I think is more important, and as long as you do your best to be as objective and fair as possible, I think it’s fine.
Another issue is how to interpret such results, and in the end, the committee must make a decision and it doesn’t necessarily has to be the most popular one — but in that case communication is key, explaining why.
Anyway, we’ll fix it with this poll and we’ll open up the thread for discussing this syntax, pros and cons, and the committee can then re-evaluate at the next meeting. And if ^() is technically the best solution, we’ll have plenty of discussions to back it up. In the end I don’t care what the result will be (nor can I predict it), since I know if we truly openly discuss this, we will find a very decent path forward.
@rwmsu , you may review this post in another thread and then reply back here to the “That’s not quite fair” comment with “But why? You have problems with facts and truth?”!!!
Your analogy is actually quite apt, that other post does show “some are more equal than others.”
…