Why no punch_unit in iso_fortran_env?

Humor
1

It has come to my attention that we are missing something in iso_fortran_env. After careful study of the Fortran 90 i1mach.f90 it seems we can update it even more using Fortran 2008. We can replace some of the last few hard-coded value with these intrinsics:

i1mach(1) = input_unit    
i1mach(2) = output_unit   
i1mach(4) = error_unit 
i1mach(6) = storage_size(1) / storage_size(' ')

Which leaves only one missing:

!     I1MACH( 3) = the standard punch unit.

Which currently just has a value of 0:

        CASE (3)
          I1MACH = 0 ! Punch unit is no longer used

Is it too late to get punch_unit into Fortran 202X iso_fortran_env? Why wasn’t this added before? :slight_smile:

4 Likes
2

Depends on what kind of punch you want to output. Rum punch, vodka punch,
bourbon punch, or some fruit laden non-alchoholic variety :grin:

3 Likes
3

I fear it would transform Fortran into a punching bag outside our community… :face_with_head_bandage::hammer:

I read in Abstracting Away the Machine that the original FORTRAN compiler had the PUNCH intrinsic, similar to PRINT but for punched cards. But it was already more modern with WRITE TAPE and WRITE DRUM. It was so long ago they do not even appear in the Deleted and obsolescent features section of the Fortran standard… :t_rex:

1 Like
4

The original FORTRAN was not a standard.:slightly_smiling_face:

3 Likes
5

Oof, I guess Fortran doesn’t care about backward compatibility after all. Might as well eliminate implicit typing, implicit save, and fixed-form source.

8 Likes
6

Is it not already planned for the Fortran 2057 standard? I think we can expect that “century” version to be a major one. Good news, Ph.D. students can hope to use it before retirement! :older_man: :older_woman:

4 Likes
8

Oh I didn’t know about those two. Thanks!

9

Oh yes, Fortran 2057 is going to be epic! Two new arguments to implicit none, yet a third half-baked implementation of enumerators, 10,000 new IEEE routines that nobody needs, and two new trivial string manipulation routines (uppercase() and lowercase()). Unfortunately, exception handing will again be postponed so there’s time to “get it right”. No need to be hasty.

6 Likes
11

@vmagnin brought up Annex B Deleted and obsolescent features which clearly shows there are limits to backward compatibility in Fortran with the following notable features having been deleted after Fortran 90 was published:

  1. “Real and double precision DO variables”
  2. “Branching to an END IF statement from outside its block.”
  3. “PAUSE statement”
  4. “ASSIGN and assigned GO TO statements, and assigned format specifiers”
  5. Hollerith “H edit descriptor”
  6. “Vertical format control”

Recently at work I came to know of a team using licensed commercial software from a company based in northeast US with a legacy FORTRAN backend that was refactored to

  • avoid implicit mapping (nearly 95% of the subroutines and functions use IMPLICIT NONE, the remaining IMPLICIT INTEGER(I-N), DOUBLE PRECISION(A-H,O-Z); this was about 30 years ago,
  • make all Fortran subprograms recursive and reentrant; this was about 12 years ago - as part of this, legacy COMMONs used initially were somehow mapped to C structs (I don’t have the details as to how) and migrated to a C driver layer and the Fortran code was checked thoroughly to have no SAVE attribute with any objects.

However for some unstated reason they retained the use of Hollerith constants and H edit descriptor and also the vertical spacing for use with the reports being generated! That is, continue to use items 5 and 6 included in Fortran 90 standard but which were later deleted.

Thus the fact this codebase “breaks” due to deletions from the standard after Fortran 90 is supposedly ok but asking the Fortran standard to standardize a couple of crucial practices such a codebase would like e.g., default of IMPLICIT NONE is not ok is not at all healthy for Fortran. It makes it an animal farm at present with some more equal than others.

If the above 6 items could be deleted, backward compatibility be damned, then implicit mapping and implied save can also be deleted.

12

My proposition is:

implicit none except i

Mathematicians put aside, who would on Earth need to declare a non integer i variable? :alien:
How many code lines could be saved by that exquisite feature? Our productivity would be improved and some bytes would be saved on our hard drives.
I even propose that implicit none become compulsory. But you could go back to the old behavour with:

implicit none except all

Note: now the problem is that if you want to declare an implicit variable named all, we should think about a syntax to avoid any ambiguity… :thinking: Any idea?

3 Likes
13

:sob: will that be a third type - enumer - to one-third-fix the two from the Fortran 202X currently in the works: enum types and enumeration type? :sob:

2 Likes
14

My preference would be to rip out the old nonsense quickly, like removing a band-aid!! The sooner the better. Modern Fortran is a great language, but the old stuff is an embarrassment, and constant source of errors and confusion. It just has to go. Why delay? There’s no reason to trickle out the deletions over decades, just do it all at once. Everybody knows what needs to be removed (the stuff nobody should be using in the first place).

1 Like
15

how about

implicit none except LOCAL(*) DEFAULT(NONE)
1 Like
16

Oh God, make it stop!!! :open_mouth:

17

Beautifully verbose…

18

According to ISO_FORTRAN_ENV (The GNU Fortran Compiler) NUMERIC_STORAGE_SIZE is “The size in bits of the numeric storage unit.”

That seems ill-defined to me. What does it mean “numeric storage unit”? Is that always the same as storage_size(1) (which is clear is the storage size of the default integer)?

19

How about allowing regular expressions in implicit statements?.. that way we can really be specific about what variables we are talking about.

1 Like
20

It’s always an option to fork Fortran and make a better language and implementation. Users who don’t need backward compatibility probably don’t need the standard, so why chain yourself to the standard? To help with the new effort, here are some name ideas which I think would be cool for the new language:

  • NewFortran
  • NeuFort
  • BetterFort
  • BackusLang
  • YOLOFort
  • Fortran 3000
5 Likes
21 
implicit double precision (\W|^)po[#\-]{0,1}\s{0,1}\d{2}[\s-]{0,1}\d{4}(\W|$)
2 Likes
23

There is only one choice:

  • Fivetran
6 Likes