Welcome to our forums
How about allowing not to use parentheses in format specification like in this example
read (75,'(i6)') variable
and allowing just this
read (75,'i6') variable
They are absolutely useless and only add you troubles with complex formats to count left and right parentheses
The outer parentheses are required syntax. Without them Format reversion would not work in a consistent way for cases where there are no 'internal' ones.
I do not see the problem here, can you show an example killing the idea?
To me, instead of format control to return to the initial opening parenthesis of the format specification in this case (which is useless because contains no information) it will return to the first symbol of the format specification which is the same thing 😃
Reversion When the last closing parenthesis of the format specification is reached, format control determines whether more I/O list elements are to be processed. If not, format control terminates. However, if additional list elements remain, part or all of the format specification is reused in a process called format reversion.
In format reversion, the current record is terminated, a new one is initiated, and format control reverts to the group repeat specification whose opening parenthesis matches the next-to-last closing parenthesis of the format specification. If the format does not contain a group repeat specification, format control returns to the initial opening parenthesis of the format specification. Format control continues from that point.
My favourite extension to the fortran standard is to use the DO variable as an alternative name, such as:
DO I = 1,n
DO J = 1,m
IF (logical) CYCLE I
...
END DO J
DO J = 1,m
IF (logical) CYCLE J
...
END DO J
END DO I
For CYCLE or EXIT, the possible values of a DO name is limited to the nest level of DO loops in use. There should be no confusion where there are two J DO loops in the example above. The inclusion of 'END DO variable' improves the readability of the code. Over many years I have never been able to convince anyone of the value of this change. Apparently improving readability of code is not important. I sometimes resort to 'END DO ! I'
John
...because it takes time to comprehend, estimate if this will not hit the performance, brake legacy codes etc, and for users to get larger programming base with CYCLE and EXIT which are still not as very common etc. Plus developers have other hatching ideas which are almost ready to be implemented and they are permanently estimate which one is more urgent based on users demand or more easy to implement. The suggestion makes sense. I suggest you ask again later.
As to END DO I, that is also very good suggestion. To make something similar I almost always use comments like these END DO ! I=1,n_divisions or ENDIF IF ! (Lorentz.gt.Doppler) then or Else ! (dwavelengthInit.gt.1.e3) all the time, i'd die without them. With this respect the readability of older loops and IFs wiith the label is much better then labelless ENDDO and END IF. I remember the discussion about that years ago and think the advantages of labelless approach is pure BS because it kills readability in larger complex codes with many DOs and IFs . But since people and myself adopted it, your suggestion to improve readability of labelless DOs should be definitely pushed forward
[quote='DanRRight']I do not see the problem here, can you show an example killing the idea?
The Fortran standard allows anything to be included after the trailing bracket. Like this contrived example:
write(*,'(I5) THIS IS IGNORED') 10
The following code needs the brackets to work. The first format specifier is seen as the character array '(I5) (F5.0)'. Without the brackets it would look like 'I5 F5.0' which would be an error. A compiler is not required to detect this error (how could it?) but a run time error should be generated.
The standard says:
'If the format specifier references a character array, it is treated as if all of the elements of the array were specified in array element order and were concatenated. However, if a format specifier references a character array element, the format specification shall be entirely within that array element.'
character(len=6) :: fmt(2)
fmt(1) = '(I5)'; fmt(2) = '(F5.0)'
write(*, fmt) 10 !< Here the format specifier is '(I5) (F5.0)'
end
Quoted from JohnCampbell
Over many years I have never been able to convince anyone of the value of this change. John
You can already do this with Silverfrosts FTN95 John so someone has listened to you. The following works for example
i: do i=1, 100
j: do j=1, 100
exit j
end do j
end do i
It has no sense to keep the parentheses just to able to write trash in the format which has no purpose whatsoever. I'd understand that parentheses worked at least somehow, say, as separator making the following format equivalent to '(i5,i10)' for this code to work properly
write(*,'(i5)(i10) junk') 12, 100000000
end
but they don't, the (i10) part is similarly useless and is ignored as the word 'junk' after it. How such proposal to allow junk in format came through Fortran Standard committee while object oriented features still did not? 😕
And that's cool
[quote='davidb']
[quote:d47f010b7c="davidb"]
i: do i=1, 100 j: do j=1, 100 exit j end do j end do i
Providing a name for a do construct is part of the Standard.
Other compilers do not allow you to use a name that is the same as the name of a variable but as far as I know this is not explicitly excluded in the Standard.
So the following should be portable...
ii: do i=1, 100
jj: do j=1, 100
exit j
end do jj
end do ii
I'd use this immediately but need to know how long this labeling exists to make sure this will be portable. When this emerged in the Standard? Will this labeled DO work with FTN77 or gFortran which is mostly 77 ?
Do similar readability improvements exist for IF-THEN-ELSE-ENDIF ?
David,
You use of named do does not work easily with the example I gave: DO I = 1,n DO J = 1,m IF (logical) CYCLE I ... END DO J DO J = 1,m IF (logical) CYCLE J ... END DO J END DO I
In this example there are 2 DO J loops, but only one of them can be the valid cycle of exit destination.
My point is that the use of names on CYCLE, EXIT or END DO is an inefficient use of names and the DO subscript would be a much better name for loops where a subscript is used. It is improves teh readability of the code.
John