Well, some corner cases might be tricky or weird, but I actually find the repetitive behavior very cool, especially if you wish to print an array with certain element formatting and with a certain nr. of elements per row (as often done for human readable scientific output):
program test
implicit none
real :: array(6)
array(:) = [1.0, 2.0, 3.0, 4.0, 5.0, 6.0]
print "(2(ES23.15))", array
end program test
I do quite a few formatted tables. I like, and use, the repeating behavior. It is restarting with the left-bracket that matches the second last right-bracket that gets me.
Section 13.3.1 in the 2018 standard indicates comma as optional, but then states (C1302) that it shall not be omitted… Strill gfortran formats this correctly :
As discussed above, the parentheses are part of the processing, whether for the whole format string or embedded within the whole format string. Fortran formats are a whole language within itself. When a programmer constructs a format string on-the-fly, he is basically writing a program that is interpreted by the i/o library.
This can, of course, be done now in two different ways, by using trim() on the output string or by using substring addressing (perhaps with a previous len_trim() function reference) on the output string. Apart from compiler optimizations, the latter is more efficient than the former because trim() usually involves scanning the string, allocating memory, and copying the contents. F2023 introduces yet another way to accomplish this with the AT format field, which works “as if” a len_trim() substring expression had been written. I expect I will use this new feature when it is supported on all my compilers.
Quite frankly, if - devil forbid - Fortran ever ends up imitating printf or fprintf just because C uses a different way to format output, I would consider it the exact opposite of language enhancement.
Should we even imitate the ridiculous \n that has to be in the end of each format string, otherwise there will be no line feed, while 99% of the time that is what it is needed? And while we are at it, why not adding a mandatory break in each and every case of a select case statement, again to imitate C, even though it makes absolutely no sense? Oh, and maybe get rid of all array features, and even arrays themselves, using pointers instead - you know, for further C-like “improvements”?
Don’t get me wrong. I’m not saying C is trash. I’m saying C is a low-level language - a high-level assembly, if you will - and it certainly has its uses for what it is. But I see no reason to imitate its printf or most of its features (or lack of features.) Since I play a lot with iso_c_binding lately, I often have to load a C program in Emacs and gradually “translate” it to Fortran. Sometimes I do the opposite for testing. The last problem I have in this process is to translate printf statements to their Fortran equivalent, or vice-versa.
Fortran’s format strings are not bad at all. They could be better, sure, but not by imitating their C equivalent.
I don’t think that follows. Let’s say you convince me that break and a terminating \n are bad ideas. It does not follow that other features that happen to be in C must be bad for Fortran. If you don’t want to borrow from C because C is a lower level language, then why not borrow from Python, which is a higher level language?
print("My name is %s" % name)
Notice the absence of a terminating \n, just like you wanted.
Don’t think of it as catering to C users. Think of it as catering to Python users. Surely that’s a prime target for Fortran — Another high level language that is popular in scientific computing.
First of all, I have no intention to convince anyone. As for the two features you mentioned, I think that, objectively, they are both bad ideas - with the former actually being a very bad idea.
Assuming you are trying to do a comparison here, python is not a higher level language. It is a high (not higher) level language, and it is interpreted. That means there is no comparison. I’m sorry but I don’t see much (if anything) I want to borrow from Python, except maybe its success.
Honestly I don’t see this as a prime target for Fortran. In fact, I don’t see it as a target at all. How this language is popular for everything nowadays, including even scientific computing, is beyond me. Putting aside the syntax (which may or may not be appealing to someone,) the fact it is interpreted should suffice to look for something else, especially for scientific computing.
In my humble opinion, if there is anything we have to learn from Python, that is is how an interpreted language managed to be that popular. I would expect it to be just another scripting language pretty much like Lua and others, perhaps with some success in simple and not very demanding multimedia and GUI applications, for the sake of simplicity.
Years ago, I wrote a Numerical Analysis library for a Casio ClassPad 300 - something between a palmtop and an advanced programmable calculator. I still have the source code somewhere, and the manual I wrote for it. The library was written in Lua and was able to do several nice things (up to solving initial and boundary value problems) and also provided graphics capabilities. It was used by the ClassPad community back then, because the machine lacked built-in numerical methods worth mentioning. I’m guessing that, if anyone is still using that machine, they probably still use the library as well. But the important thing here is I wrote it in Lua not because it was a good idea but because it was the only option I had in that machine. I admit it was a nice experience, mainly because of the challenge of using an interpreted language for scientific computing - and the tricks I had to learn to make it work with acceptable computational times, given the limited hardware and the even more limited language used. But I’d rather write it in any compiled language (even C), if that was an option.
I’d just point out that this is the old format syntax originating from Python 2. In Python 3 the new and more powerful {} + .format() syntax is the recommended one.
Addendum: the PyFormat website gives a nice comparison of the old and new. Also good as inspiration for a future Fortran-lang format edit descriptor page.
I agree. As @RonShepard reminded, the Fortran formating syntax is quite powerful, and I don’t think the C (or python) one is on par with that. The downside is that it is a bit less readable, but the C syntax is not more readable enough to make it worth considering.
Taking good things from other languages is one thing, imitating them is another thing (I’m still puzzled by the C-like choice for the conditional assignment ternary operator in F2023).
Should the formating syntax be improved or simplified for the simplest cases, one should think about something really better, not just different.
I don’t think it does. You are taking the example of unlimited range integer arithmetic in Python, but most Fortran compiler propose 128 bits floating points, which are not hardware native on usual machines.
I get an overflow. Python hides the reality of the hardware by auto-magically converting to BigInt.
Btw, I’m not saying that this auto conversion is a good thing. It is one of the reasons why it is not possible to make Python fast (without restricting it). But Python does hide the hardware more and it does abstract things more.
And similarly you can use real(kind=real128) on most Fortran compiler, although there’s nothing like a native 128 bits floating point type on most hardware. The fact that Python automically casts to a BigInt is another story, unrelated to hardware abstraction.
The closing parenthesis does tell the format interpreter where the end of the format string is. That seems like a “reasonable” reason for it, considering the intense shortage of valid characters in Fortran-77.
Eh? Fortran integers can’t overflow. They just give wrong answers if they “should” have overflowed. But the absence of integer Infinity is a nuisance that could be fixed only by IEEE, who presumably have reasons for not wanting to. My little program on this topic and its output from gfortran are