We should choose our battles. I find the choice of % definitely suboptimal (although a good IDE can improve on it a lot), but I do not think, it is worth the effort to try to change it. But we should definitely try to fix the constraints, which make people to abuse .operators. for workarounds…
7 Likes
I would use all my limbs to sign under that statement… But I feel like this is a long time until that gets fixed, so until that time we need the workaround 
1 Like
And yes, not being able to chain()%function()%calls() is killer. I use that all the time in Python and not being able to do it in Fortran is like going back to the dark ages.
1 Like
As have been mentioned, I feel that perhaps you could change the color of operators, so that it is easier to see the % and other operators.
If you are using Visual Studio, you could do the settings like below, and I am pretty sure other editors can do similar things and perhaps even better.
2 Likes
@certik, being unable to chain type-bound procedures is the motivation to use generic operator facility which is a separate issue.
It has little to do with the choice of % character versus some other, say .
1 Like
My point is this: if we fix the chaining of %, then there might be little need for custom operators .custom..
In Python and C++ you also can’t naturally create custom operators (you can with various hacks, but it’s not a first class language feature), you can only override existing operators (which you also can in Fortran). This seems to support my suspicion that custom operators are not a very widely used feature. (Overriding existing operators is a widely used feature.)
As a consequence, requiring some extra space or extra parenthesis for the rarely used custom operators to disambiguate some corner cases might work very well in practice. And this opens up the door to actually use . for % as an additional syntax, similar to [ ] for (/ /).
On my personal list of priorities this is currently low, but the door is not closed to this, so far I have not seen a road block in any of the comments above.
@FortranFan are the arguments against that made the proposal fail available somewhere?
1 Like
@hkvzjal sometimes there might be in the minutes from the meeting, but in general no. However that was the reason I started GitHub - j3-fortran/fortran_proposals: Proposals for the Fortran Standard Committee, to be able to document the discussion about each proposal. So I just created a dedicated issue for chaining the % operator: Allow to chain the % operator · Issue #317 · j3-fortran/fortran_proposals · GitHub, let’s document the technical reasons why it was rejected there, and see if the technical objections can be fixed.
4 Likes
chain()%function()%calls() can be written in Fortran using the following style to achieve a similar effect?
associate (obj1 => chain())
associate (obj2 => function())
call obj2%calls()
end associate
end associate
Overall, it feels like Fortran is still a bit plain and doesn’t provide the user with a relative amount of syntactic sugar, except for array vectorization operations?
I don’t think anyone really likes %. Why not tilde? foo~x is more readable that foo%x, and tilde is not used anywhere else, so no conflicting issues like dot. It may look a bit like “foo minus x”, but with a nice curly tilde this won’t be a problem. -> would waste space and it’s not much better than % in my opinion.
@Pap , though likings may vary individually, IMHO one thing not to be forgotten when making such “impacting decisions” is compatibility. As far as % can be bad-looking visually, it is a character present (and also sharing the same actual physical key) in all layouts I am aware of. ~ is not as universally present (unfortunately I might add).
I don’t really know the reasons which brought to this final choice, but I’d like to think this aspect was indeed part of the decisional process.
@mEm, you are probably right. However even the common VAX minicomputers of the 70s-80s had a tilde key in their iconic terminal. But then again, that’s just an example, go figure what keyboard they had in mind - probably the most generic one.
The % is not present in the default Czech layout, for example. However I think it’s a good idea to always use the English keyboard layout for progamming, and then most keyboards have both % and ~. Which keyboard with English/US mapping doesn’t have the ~ character?
Even if present on the keyboard, the ~ may be less practical: on my Fr keyboard it is on the touch 2 with Alt Gr: I must use both hands. Whereas % or . can be typed with the right hand, the little finger on the Shift key plus another finger for the character.
1 Like
@certik , with all the due respect, this image should depict the Czech keyboard layout, as per the global QWERTY keyboard layouts wikipedia page. It shows that the % is Shift + =. It doesn’t show ~ though.
But indeed, you surely know much better, and this picture could not be representative.
1 Like
@mEm you are right! I forgot it’s above =. I always switch it to English to type it though, since it’s hard for me to remember all these alternative locations. I was wrong, it is indeed there.
I find the percentage sign much more visible/readable than the dot sign…
1 Like
I have thought about this too. I have never really gotten used to % but it doesn’t bother me anymore.
So, if this is simply an esthetical issue, why not use the awesome editor technologies and esthetic symbols (not bound to ASCII) to make our life more esthetically pleasing?
Being a (Neo)vim user, I really like what @Euler-37 (thank you, btw!) wrote in the beginning of this thread. I haven’ tried it but the next thing I will do on my computer is to try that. Also @themos had a very nice demonstration for Emacs.
So far I haven’t heard any arguments against those solutions.
I have been impressed by something in stdlib I noticed: just using a single space on either side of % makes code much more readable.
BTW I recently encountered an online description of Fortran which explicitly states that white space either side of % is not legal! I have messaged the author.
2 Likes