Label renumbering tool?

[Massimo]

Greetings,

my code is growing fat and I start having problems with label numbers. Do anybody know a tool to sequentially renumber the labels?

(disclaimer: I did a forum search, but I got only a few unrelated posts).

Thanks in advance.

[Steven_L_Intel1]

In modern Fortran, there's very little need for label numbers, except maybe for FORMAT statements if you're not using inline formats. 

A Google search on "fortran label renumbering" turns up several interesting leads, though the first few I looked into were "stale" and not available.  You might keep looking.

[mecej4]

Polyhedron's SPAG (http://www.adeptscience.co.uk/products/fortran-tools/plusfort-with-spag/spag-fortran-code-restructuring.html) can do what you want. It has a large number of options, and is available as an evaluation version with some options blocked, and as a licensed version (that was as of a few months ago; now the ownership seems to have become a bit different, so you have to check).

The NAG fortran compiler (http://www.nag.co.uk/nagware/np.asp) comes with a tool called "polish" that is easy to use and will probably do most of what you want. A few years ago, that used to be part of a separate product, NAG Fortran Tools, but now some of the the tools have been made part of the compiler package.

[FortranFan]

Steve Lionel (Intel) wrote:

In modern Fortran, there's very little need for label numbers, except maybe for FORMAT statements if you're not using inline formats. ..

Yes, with the improving facilities for string handling in the Fortran standard and increasing compiler support for them, one can do without labeled FORMAT statements too:

program p

   implicit none

   character(len=*), parameter :: my_format = "(A)"

   write(*,fmt=my_format) "Hello World!"

   stop

end program p

[JVanB]

I end up using numbered statements for END=, EOR=, and the like. Let's let the thread drift into FORMAT statements, like https://software.intel.com/en-us/forums/topic/516257#comment-1806762 :)

[Steven_L_Intel1]

Preferred usage in I/O statements is IOSTAT rather than label branching. Just sayin....

[FortranFan]

Repeat Offender wrote:

I end up using numbered statements for END=, EOR=, and the like. Let's let the thread drift into FORMAT statements, like https://software.intel.com/en-us/forums/topic/516257#comment-1806762 :)

In that other thread, the idea to use FORMAT statement to null terminate a string was shot down by Steve and it made sense.  If the OP could use ISO_C_BINDING and C interoperability features in Fortran 2003 and later, then that would be a better approach since the use case seems to be Windows functions that are in C++.  Now I am not up-to-speed on Fortran 2015 features for extended interoperability with C, so I simply use an overloaded F_C_STRING custom procedure written with standard C interoperabilty features in Fortran 2008 that returns me a null terminated C-style string using C_NULL_CHAR named constant from ISO_C_BINDING.

Coming back to labeled statements, even for I/O exceptions processing, one can do without them if that's a style one prefers.  Processing based on IOSTAT values, as suggested by Steve, is rather convenient:

  ..

   use, intrinsic :: iso_fortran_env, only : iostat_end, iostat_eor

   ..

   read(unit=lun, fmt=my_format, iostat=istat. iomsg=errio) foo
   select case ( istat )
      case ( 0 )
         !.. normal operation
      case ( iostat_end )
         print *, " end-of-file encountered during read: ", errio
      case ( iostat_eor )
         print *, " end-of-record encountered during read: ", errio
      case default
         print *, " error encountered during read: ", errio
   end select

  .. 
   

The language also includes elemental intrinsic functions of IS_IOSTAT_END and IS_IOSTAT_EOR as an alternate option.

[andrew_4619]

Back to the original post... SPAG I think does the job as others have said but is perhaps a costly and an overkill solution  if the only issue is line numbers.

I would suspect line numbering is only and issue when you are editing code and find the original scheme of the number  increasing down the page is hard to maintain. I think Steve's suggestion is a good one (and is the way I work) and to stop adding new line numbers (and eliminate a few as you go). For example DO <number> .......... <number> CONTINUE loops become DO ......END DO.  You will find other than the odd format number is is no need to add any new line numbers as there is a more 'modern' way to do the same thing.

[TimP]

Replacing original numeric labeled DO with f90 labeled DO isn't a trivially automated task.  Automatic indentation might be a partial stop-gap but I've seen minimal acceptance of it.

[andrew_4619]

Tim Prince wrote:
Replacing original numeric labeled DO with f90 labeled DO isn't a trivially automated task.

True but in most cases a label isn't needed / doesn't add anything unless the start / end are a long way apart. Indentation does aid readability but good editors highlight loop start/end and or add folds anyway. My point was that if when editing code if you do not add new numbers there probably isn't a problem that needs to be solved. 

[Massimo]

Thanks everybody for your answers. I definitely need an update to some more modern FORTRAN (learnt back in the '80s), the problem is that my programming activity is rather occasional - not the bulk of my job - and I have very little time for an update study period (I probably need a week intensive update course, which is hard to find at my place). I'll try the DO - END DO structure (I'm still using the labelled DO), that should fix most of my problems. I'm not going to buy a commercial software just to do some label renumbering.

[dboggs]

I am a semi-proponent of "no statement labels" and a big proponent of no-label blocks DO - END DO, IF-THEN-ELSE IF-END IF. But I have two exceptions.

(1) If the blocks are nested very deep, then (and I don't care how short the blocks are) then the logical path through them can get quite obtuse and difficult to follow. A sparsely used and well placed GO TO can sometimes simplify the logic immensely.

(2) Sometimes the length of a procedure can grow quite long, for example when it contains a sequence of similar blocks that read various input sections from a file (and no, they are not similar enough to be processed by CALLing a single subroutine). Using an editor with a limited window view to the code, it is easy to become disoriented and loose track of where you are in the procedure. This can be helped by simply starting each block with NNN CONTINUE ! segment to do ... where NNN advances by 10 each time. These numbers, then, play the role of page numbers in a book so you can tell where you are. Ever try reading a book without page numbers or chapter numbers?

In short, I don't think that the mantra "no statement labels" should be taken so literally as to lose the rare advantages they can sometimes serve. I think the mantra got overblown in the days of anti-spaghetti code crusading. You can easily accomplish spaghettiless code if you just take some care, and be fully aware of its danger.

[IanH]

dboggs wrote:

I am a semi-proponent of "no statement labels" and a big proponent of no-label blocks DO - END DO, IF-THEN-ELSE IF-END IF. But I have two exceptions.

(1) If the blocks are nested very deep, then (and I don't care how short the blocks are) then the logical path through them can get quite obtuse and difficult to follow. A sparsely used and well placed GO TO can sometimes simplify the logic immensely.

(2) Sometimes the length of a procedure can grow quite long, for example when it contains a sequence of similar blocks that read various input sections from a file (and no, they are not similar enough to be processed by CALLing a single subroutine). Using an editor with a limited window view to the code, it is easy to become disoriented and loose track of where you are in the procedure. This can be helped by simply starting each block with NNN CONTINUE ! segment to do ... where NNN advances by 10 each time. These numbers, then, play the role of page numbers in a book so you can tell where you are. Ever try reading a book without page numbers or chapter numbers?

Use of construct names can assist with both of these, with the benefit of a name generally being more descriptive than a number, plus perhaps additional guarantees from the syntax rules of the language.    

the_initial_loop: DO i = 1, 100
! ....
END DO the_initial_loop

the_big_if: IF (some_condition) THEN
  !....
  EXIT the_big_if
  !...
ELSE the_big_if
!...
END IF the_big_if

Some programming styles frown upon procedures that are too long to be followed without lots of "paging".

[FortranFan]

dboggs wrote:

.. I don't think that the mantra "no statement labels" should be taken so literally as to ..

I don't think anyone here is suggesting any draconian diktat against statement labels, the message is simply that if one preferred to code without numbered statements, there are options in the language to do so.

And with the EXIT facility in the language being available in all the control constructs, the same idea can be extended to GO TO statements as well i.e., it's possible to write good code that is easy to follow and maintain in terms of logic using appropriate EXIT.statements, if that's a preferred style.

Expanding upon the concept of construct names mentioned by IanH in Quote 13, one can apply such names to SELECT CASE, ASSOCIATE, BLOCK constructs also and I personally prefer to do so..

[Massimo]

Well, I'm getting a bunch of error messages when trying to convert my 77 code to 90. For the time being I'll keep the label, as soon as I have some spare time I'll try to understand what's going wrong.