Which five features should Fortran 202Y implement?

Open and inquire on URL =?

@fortran4r Can you please send a PR to fpm?

The thing I don’t like about this suggestion is that, as you show, there is already a simple, straightforward, and clear way to achieve the same result. Adding INIT or NOSAVE or whatever is the new keyword is redundant, and it is just one more unnecessary thing that both programmers and compiler writers would have to worry about.

I always include the SAVE attribute whether the entity is initialized with a data statement or on the declaration line. It is redundant, but it makes it clear what is happening, and this separates the two cases (initialization at compile time and initialization in an executable statement) more clearly. Adding something in the middle, that looks like one thing but is really the other, is not productive. Short of changing the standard and introducing backwards compatibility problems, I think compilers should at least print warnings when an implicitly saved entity occurs in an initialization statement, and if compiler options are available to enforce that, then programmers should be encouraged to use those.

Do any compilers (or style checkers) warn about this? The consensus here (which I agree with) is that it is bad practice, but I haven’t ever seen warnings about it.

INCLUDE too; which would technically not be non-standard even now (the definition of what the argument to an INCLUDE directive is pretty general. An INCLUDE that would get files like curl(1) or wget(1) is something I have wanted in the past; picturing something like a netlib repository or github/gitlab/… repositories. Not aware of any compilers that take anything but a filename. I made a preprocessor directive that you could give commands to like wget(1) or even echo(1) commands to get things like environment variables that was useful, but have to be used judiciously with general commands ot you can very quickly get very OS-dependent; a URL is less general and safer. If you did allow a process like popen(3c) does it really would not work with INQUIRE but would be really useful.

Here is a quick and hacky patch for making implicit none the default for one compiler in fpm using the option build.implict-typing in the manifest:

Full details on the implementation are available in Support disabling of implicit typing in package manifest · Issue #577 · fortran-lang/fpm · GitHub. The overall setup needs more thoughts before this can be become a proper patch for fpm. If anyone wants to take this up, feel free to comment in the linked thread.

1 Like

I would call the current situation machine-dependent rather than non-standard. Namely, the filename syntax depends on the local file system conventions.

However, this idea of allowing URLs in the include statement is interesting. Currently, this task is accomplished by downloading the remote file to a local file, possibly testing for any differences before replacing the local file, and then invoking the build process. If the include file has changed, then it would presumably trigger any necessary recompilation steps. Sometimes the fetch process itself can determine if the local file needs to be updated (through svn or git or whatever).

There was a recent discussion (in comp.lang.fortran I think) about physical constants that are available online from the NIST web site. The idea was about automating the process of getting the current standard values for physical constants (speed of light, planck’s constant, avagadro’s number, and so on) into a fortran module, which could then be USEd. The constants change every few years as new experimental data is incorporated into the overall dependency scheme, and sometimes the designation of fundamental constant and derived constant changes. This might be accomplished in part with an INCLUDE statement that references a URL.

1 Like

Is it possible to introduce block comment like C++'s /* ... */ in Fortran?
Well, after some google it seems

#if 0
things you want to commented.
#endif

with the -fpp compiling flag can do the block comment trick.

My top 5:

  1. A significant generics feature that allows for creating a composable library ecosystem not just for different real kinds, but also for automatic differentiation.
  2. Exception handling.
  3. Removal of the bad old language features (implicit typing, implicit save, fixed-form source, etc.). Just delete them all in one fell swoop, there’s no need to trickle these away over decades.
  4. A real string class built into the language. That allows us to have arrays of different-sized strings, and also allows use of the slice syntax (something none of the hand-rolled string classes we can write now can do). Must be supported by all intrinsic routines that accept or return strings (read, write, etc.)
  5. Some kind of alternate parallelization that works more like Python multiprocessing, where we can on-the-fly launch new processes while the program is running. Must work in libraries written in Fortran, but Fortran may not be the main language (e.g. a library called from Python).
4 Likes

This is what I currently do, and have done for some 30 years, and I have found it to be widely supported and reasonably portable. However, the C preprocessor is not really part of the fortran standard, so we would also need to add that to the top five list.

I have a few files where I have #if 0 ... #endif blocks that are a few hundred lines long. They are basically a small paper describing the algorithm and the argument conventions that are built right into the fortran file itself. That way, I know the fortran code and the documentation will not be separated or out of sync.

1 Like

At the moment, I’m in favor of looking at F202y (hopefully out in 2028 for the 70th anniversary) as a chance to make a limited number of non-backwards compatible changes as well as add important new features. So my list of 5 (well, 6) things probably looks like

  • generic programming (I’m worried about the power of our typing system, though)
  • better rank-agnostic programming (maybe a subset of the generics or maybe like Mathematics of Arrays where we treat array indexes as function transformations)
  • concise error handling (not necessarily exceptions)
  • forcing explicit typing
  • standardize minimal preprocessor support (cpp-like, presumably)
  • minor language convenience features: +=, -=, …, non-SAVE initializations, multi-ASSOCIATE instead of nesting, etc.

An area that I can’t speak to, but that seems important is enhanced support for parallel computing and hybrid computing (DO CONCURRENT and beyond). It seems it’s what Fortran is for, these years.

7 Likes

In a current code I have

call fit_arch(zret,arch_wgt,arch_coeff,log_lik_mle(iarch),arch_var_min=arch_var_min,xvar=var_pred_mle, &
              asymm_twist=asymm_twist,asymm_shift=asymm_shift,dist=cond_dist_vec(idist)) ! out: arch_coeff(:), log_lik_mle(iarch), xvar(:)

I only wrote it a few weeks ago, but without the comment I would already be confused about what it does. I’d like the ability to annotate actual arguments with intents in procedure calls, so that one could write

call fit_arch(zret,arch_wgt,out:arch_coeff,out:log_lik_mle(iarch),arch_var_min=arch_var_min,out:xvar=var_pred_mle, &
              asymm_twist=asymm_twist,asymm_shift=asymm_shift,dist=cond_dist_vec(idist))

If this proposal were adopted and implemented in compilers, projects could require that all intent(out) and intent(in out) arguments in callers be so annotated, which would increase clarity. The reader could assume that non-annotated actual arguments correspond to intent(in) dummy arguments.

1 Like

An FYI for prep(1) preprocessor users is that IF directives by default must be logical expressions so “#if 0” will not work by default with “–prefix ‘#’”; you must use the “-fpp” switch. I very much prefer keeping documentation and/or references to documentation with the source as well so prep(1) has a lot of options for that, including changing blocks of text to comments and/or writing them to separate files; so I do not use this method of embedding text any more myself, but I see that usage in others’ files.

Because of variations in cpp and fpp when I used something similiar I found “#ifdef DOCUMENTATION” a little more portable, as some other preprocessors also enforced the arguments to a #if to be a logical expression.

Many preprocessors also support /* … */ C-like comment blocks as well, but I also found that was not true of all default processors, at least in the past.

One of the tests for the prep(1) -fpp switch tests that “#if 0” syntax …

  fpp mode tests
#if defined(_CRAYFTN) || defined(__NVCOMPILER)
  BAD: ONE DEFINED
#else
  GOOD: NONE DEFINED
#endif
  
#define _CRAYFTN
#if defined(_CRAYFTN) || defined(__NVCOMPILER)
  GOOD: ONE SHOULD BE DEFINED
#else
  BAD: NONE DEFINED
#endif
 
#define __NVCOMPILER
#if defined(_CRAYFTN) || defined(__NVCOMPILER)
  GOOD: BOTH DEFINED
#else
  BAD: BOTH NOT DEFINED
#endif

#if NOTDEFINED
  BAD:  "#if NAME" NOT treated like #ifdef NAME
#else
  GOOD:  "#if NAME" treated like #ifdef NAME like cpp and intel fpp
#endif
#if !NOTDEFINED
  GOOD:  "#if NAME" treated like #ifdef NAME like cpp and intel fpp
#else
  BAD:  "#if NAME" NOT treated like #ifdef NAME
#endif
#if 0
  BAD: should not appear
#else
  GOOD: should appear
#endif
#if 1
  GOOD: should appear
#else
  BAD: should not appear
#endif
EOF
 fpp mode tests
  GOOD: NONE DEFINED

  GOOD: ONE SHOULD BE DEFINED

  GOOD: BOTH DEFINED

  GOOD:  "#if NAME" treated like #ifdef NAME like cpp and intel fpp
  GOOD:  "#if NAME" treated like #ifdef NAME like cpp and intel fpp
  GOOD: should appear
  GOOD: should appear
1 Like

In the C preprocessor, 0 is false and 1 is true. So #if 0 is indeed a logical test. That 0 is a character string, not a numeric value. The C preprocessor only works with character strings, there are no other data types.

GOOD: "#if NAME" treated like #ifdef NAME like cpp and intel fpp

This is at least a little confusing. Those two tests do not have the same meaning. Here is an example that demonstrates the difference.

#define XXX 0
#if XXX
   incorrect XXX
#else
   correct XXX
#endif
#ifdef XXX
   correct XXX
#else
   incorrect XXX
#endif

Here the macro XXX is defined, but with a value of false, so the two tests result in opposite outcomes.

1 Like

Multi-line comments are easily addressed by using a text editor that can pre-pend ! to multiple lines at once.

3 Likes

A block of free-format text would be allowed for a write statement, or be used to generate an external document or define a CHARACTER array or be available as help, not just comments. This is allowed with the $BLOCK directive in the prep(1) preprocessor and greatly simplifies code development and documentation if you desire documentation and source to be contained in a single file; as an example.
At least a subset of this is available in many languages, such as the ``` strings in python.

Would asynchronous task parallelism · Issue #271 · j3-fortran/fortran_proposals · GitHub address your #5?

8 posts were split to a new topic: Allow subarray indexing as input to pure and elemental functions

  • Generic programming

  • Standrd algorithms (search, sort ect.) based on these generic features

  • Namespaces

  • Improved error handling

  • Some concenience features concerning C interoperabiluty (e g. mapping between FIKE* poibters and fortran units

1 Like

How do you propose a compiler to process this statement ?
There is an intent from the coder in what is a legal Fortran statement.

Or, should we delete the DATA statement also ?

Forcing " integer, save :: n = 42 " just adds to modern Fortran bloat with it’s more and more verbose unnecessary text.