Too bad. That seems like a wasted opportunity. If that is ever added to the language, it will take at least another decade to do so.
You’ve been listening to crazy people - we’re currently on a five-year cadence, could be shorter if more people got involved in designing features. Feel free to write up a proposal at GitHub - j3-fortran/fortran_proposals: Proposals for the Fortran Standard Committee
2 Likes
Haha, could be. But still, this seems like an obvious feature. You have a modifiable object, one would naturally expect to be able to use it in an assignment. Do you know what were the objections to allowing it to be used that way?
I don’t recall it ever being proposed. We had a use case for conditional arguments that could not plausibly be done in other ways. I’ve never run across code that conditionally assigns to different variables. In the conditional argument case, the primary motivation was being able to conditionally omit an argument.
“Ha ha” - a decade only if you listen to fake news, actual evidence suggests a couple of decades, or never ever with most features … 
Consider this note: [J3] Proposals for new intrinsic procedures. So now @everythingfunctional is proposing certain new intrinsics for Fortran 202Y and the above note indicates several were proposed way back in 2004. It’s a familiar case with the author of that note. So anyone keen to propose a set of features have always to wonder, will they turn out to be the author of the note on the committee!
The truth is most proposals fail to pass a certain impermeable filter placed by certain vendors on the committee.
The issue is not with writing papers. But due to a lack of vision and placing the “cart before the horse”. With the work, what is needed is sincere guidance and direction on how to develop features and genuinely seek out collaboration across the entire worldwide Community particularly with new and young Fortranners - @certik shows the way with LFortran (46 contributors and growing). But that ain’t happening with most subgroups.
With conditional expressions, the papers as part of J3 development were written by one person:
https://j3-fortran.org/doc/year/21/21-157r2.txt
https://j3-fortran.org/doc/year/21/21-162r1.txt
with little to no guidance for the readers ultimately on what makes a good paper, or not. The same quality papers written by someone else would have been skewered on account of the holes, perceived or otherwise, that’s how it rolls.
dəˈnī(ə)l is not just a river in Egypt, to borrow the cliche.
It continues to shock me that anyone in the Fortran world still follows J3. It would be relatively easy for Flang, LFortran and gfortran to set up a monthly meeting over zoom/google meets/something else to replace the standards committee. This would have several advantages.
- It would allow public participation
- The resulting standard documents would be freely available
- Features could be added more frequently than every 5 years
- The language wouldn’t be held hostage by a committee that has repeatedly shown to be unable to improve the language effectively.
Readers should see this thread.
I wonder if it’s the same poor, persevering practitioners of modern Fortran who are going “crazy” that Fortran in effect looks down on user productivity and convenience, dismissing or ignoring proposals that are centered around such ease-of-coding aspects that they find are readily so many other programming languages. Mind you, these are languages that have greatly increasing usage application in scientific computing and technical programming and whose bearers place tremendous value in making the lives of their programmers easier by offering enhanced coding facilities in addition to improving performance!
I wonder what it would take to get young folks like @everythingfunctional and @FortranFan on the Fortran committee. Maybe we can create change if given the opportunity…
Nothing - they already are and have been for a few years at least. While it costs money to join as a principal member (I paid $1340 for 2023 membership to INCITS), being an alternate is free and you just have to find a principal to sponsor you. There are quite a few younger folk on the committee nowadays, at least one of which I recruited myself.
At the risk of sounding like a broken record - er - skipping CD - er corrupted MP3?, what we need is more people willing to develop their ideas within the framework imposed on us by the parent organizations (primarily INCITS as J3 operates under them.) Proposing ideas is easy, writing down exactly how it should work in the language, what syntax is usable, and what words need to change is the hard part. It’s even easier, but not helpful, to sit back and throw stones.
11 Likes
Currently there is at least one group working on such a proposal, this one concerns the possibilities for generic features. And indeed, the hard part is to specify exactly how such a feature should work. Sometimes you run into unexpected problems: how to formulate clearly what you want and, more importantly, how to make sure you exclude impossible combinations.
To give an example that we encountered this week (yes, I am involved in a small way ;)) that has little to do with generics but everything with unexpected issues:
subroutine mysub( x )
type :: mytype
integer :: y
end type mytype
type(mytype) :: x
end subroutine mysub
This looks innocent enough, but as the derived type is defined inside the routine, there is no way to call it. The code is accepted by various compilers.
1 Like
Before you ask: I wrote an equivalent C program. The MicroSoft C and the Intel C compilers accept it without complaints, gcc does warn.
One of the obscure features of Fortran is that duplicate type definitions in different scopes, even if the two definitions are identical, are not permitted. Will a compiler detect such errors and what are the consequences if the error is not detected? Here is an example:
program xyz
type :: mytype
integer :: y
end type mytype
type(mytype) :: x
x%y = 3
call mysub(x)
end program
subroutine mysub( x )
type :: mytype
integer :: y
end type mytype
type(mytype) :: x
print *,x%y
return
end subroutine mysub
One could move the three lines that define the type into an include file, ensuring that the two copies are identical, but the error would persist.
Gfortran and Nag detect the error at compile time. Intel (Ifort and Ifx) will detect the error only if asked to, with the relevant compiler option.
Do they still detect the error if mysub is compiled separately? I.e.
gfortran -c mysub.f90 -o mysub.o
gfortran -c xyz.f90 -o xyz.o
gfortran mysub.o xyz.o -o xyz
Unless the type has the SEQUENCE or BIND attribute! (There are some caveats as well.) See F2018 7.5.2.4p2.
Also, it’s not that duplicate definitions are not allowed, it’s that they are different types unless the above exception occurs.
3 Likes
Oh no, if Jim Al-Khalili starts criticisng Fortran, are we doomed?! https://twitter.com/jimalkhalili/status/1623679694049628173
The Joy of Fortran would be a nice book title.
There are blog posts like The joy of Fortran where Fortran was more suitable than Scipy/Python and R (snapshot of 2010’s toolkit of Sam Urmy, an oceanographer), or The Joy of Batch Fortran programming by Steve Sheets in 2021 (though more a reflection about his time as a freshman, when the language still was FORTRAN). No share of code by either one author.
In this regard I enjoyed modern Fortran by Radek Gruchalski (2022) is more substantial for that the author describes by example what stuck a chord. To quote some snippets:
The community doesn’t let you hang here. […] I must admit, the ecosystem is very impressive and makes picking up Fortran a fun and straightforward task. […] FPM makes it easy to create and manage a program.
Radek appreciates Milan’s book with
As a final note, during my learning, I supported myself with the Modern Fortran book written by Milan Curcic, and I can’t recommend it enough. The book is easy to follow and comes with fun examples and exercises. If you, like me, would like to dive deeper into Fortran, make sure you get your hands on a copy.
3 Likes
The posts by Urmy and Gruchalski have been added to the Fortran Advocacy and Language Comparisons section of the articles page of the Fortran Wiki, which has many others.
3 Likes
Fire in the Valley - The Birth and Death of the Personal Computer (3rd edition, 2014) is a very pleasant book. It talks far more of BASIC than FORTRAN, but here are the few citations concerning FORTRAN:
Page 155: Compared with the slow, laborious, and complex process of programming in FORTRAN, the comparable computer language in common use at the time, BASIC was a winged delight.
During the following two years, the National Council of Teachers of Mathematics debated over whether to support FORTRAN or BASIC as the standard educational language. FORTRAN, widely used in scientific computing, was considered better for large computational tasks; however BASIC was far easier to learn.
Page 156: Think of the Children - Bob Albrecht was a prominent supporter of BASIC. As a pioneer of computer education for children, he had been frustrated with FORTRAN.
Page 174: Programming languages were designed for particular audiences. Programs written in FORTRAN looked something like the math notation you’d see on a classroom blackboard or in an engineer’s office; the language had the style and the capabilities that mathematicians and engineers wanted.
Page 273: In addition, Gates and Allen had introduced other programming languages, like mainframe-originated FORTRAN and COBOL, to personal computers.
4 Likes
Can the FORTRAN code accurately model the climate!?! That has gotta be the quintessential question!