Flaw with typed enumerators in F202X

Language enhancement
#5

@zedthree, @plevold ,

Please note I serve as an alternate, non-voting member to INCITS J3 and I have been requesting and advocating for a proper enumeration type facility in Fortran 202X since 2018, right around when the work began on Fortran 202X.

My own vision and the use cases for Fortran based on industry experiences as to how a related set of named constants are preferably consumed in scientific and engineering codes are summarized in this paper.

In the above paper usually referred to as 19-229, you will find the use cases and requirements pretty much touch upon the needs and requirements the two of the you have listed upthread. For example, @zedthree what you show with name collision with the colours module was precisely what I wanted Fortranners to not encounter in their codes and thus I added a requirement:
image

My simple goal is to minimize “magic values” from appearing in Fortran code because that leads to costly mistakes and to employ mnemonics as much as possible when it comes to working with constant values that belong to a group or a set.

The above paper was submitted to J3 committee and it is drafted entirely from the user perspective, especially in industry. I failed miserably and was unable to influence the design even a bit.

So my proposal was clearly seen by the voting members of the committee as entirely B.S. but I also then failed to see anything better being proposed that could be much of any use in actual coding practice with Fortran 202X. What eventually got voted in left me aghast, that is:

  • I am of the opinion the enumeration type feature in Fortran 202X is mostly flawed.
  • It is a tremendous disservice to the actual users of Fortran to have two deeply flawed and highly confusing features, enum type in addition to enumeration type, that convey rather similar use cases and yet have very different semantics and syntax,
  • I have long been thinking whether it will be better for Fortran to get “something”, however poorly designed, into the language starting 202X that will take 10+ years after publication for compiler support only to consider improvements and extensions in 202Y and 203X that may or not happen but if they do, they will take additional 10+ years before users can consider using it in their codes. Or, whether it will be better to do-it-right-this-time. I’m inclined toward the latter.
  • Given the previous point, I have been contemplating whether to start a petition with the users that reach WG5 to withdraw the enumeration type feature from Fortran 202X considering how useless it is at this point.
  • Outside of a strong external influence on WG5 e.g, via one or more national bodies, say BCS in UK, or similar in Germany or Japan, etc., it shall indeed remain the case "the current design is set in stone."

So there you have it, one take on the situation.

2 Likes
#6

@FortranFan, this response is not directly related to the topic of enumerators, but is intended to record an example that I came across recently, in which a straightforward solution did not present itself.

In a post on the Intel MKL forum, a user posed the following question:

" According to documentation, the function should return one of a small number of values such as VSL_ERROR_OK, VSL_STATUS_OK, etc. I still haven’t been able to locate the definitions of those parameters."

These codes are, of course, defined in header files and include files provided by the compiler/library vendor (Intel). It is easy enough to write statements in your code to compare the return code with one or two symbolic integers if you know them. However, there are many possible return codes, and how does the user catch the error number and use that to print the name of the error? The user wrote, “I’m having trouble discovering what the value of 2 indicates, an error of some kind I’m assuming.”

Do any of the proposed additions to the Fortran standard, including yours, address this particular issue?

Thanks.

#7

@mecej4 , thank you for question, that is “right on the money” in terms of the use cases I (more what my peers) had in mind.

But I am afraid the current feature in Fortran 202X will not support our use case all that well.

Similar to the case you bring up with VSL_* codes (constants), please take a look at this link at NAG numeric library documentation site for a method to find the solution for a nonlinear system of equations:
https://www.nag.com/numeric/cl/nagdoc_fl26.2/html/c05/c05qdf.html

Please take a note of various dummy arguments: IREVCM, MODE, thru’ IFAIL.

This method is a common enough need in typical engineering practice, moreover the style of the subroutine (its API) is rather similar to a lot of other existing Fortran codes for other technical needs, meaning integers with magic values are used in type-unsafe fashion.

Ideally we would have liked to have modernized such legacy APIs to modern Fortran and use an enumeration type instead for arguments such as IREVCM thru IFAIL in a way where the code values are retained (IFAIL = 5 carries a special meaning in the above case). Because the specific values of codes have handled elsewhere also, often outside of Fortran context.

I believe my paper 19-229 tried to address what you bring up as well as the needs of others, but it failed.

#8

Because I am not familiar with enum (though I often see it is extensively used in other languages), I’ve just read a few documents about enum class in C++, then find various explanations about the above issue of “unscoped” enum , e.g.,

Improving Enumeration Types [N1513=03-0096]
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1513.pdf)

Strongly Typed Enums (revision 3)
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf)

Sec.2.3 of the above PDF says (the bold font is by me):

2.3.Problem 3: Scope
C++ enums are not strongly scoped. That is, the enumerators of an enum are exported to the scope in which the enum is defined. This is a relict from the earliest days of C where scoping was very weak. In the case of enumerators, there are nasty implications. In particular:
• It is not legal for two enumerations in the same scope to have enumerators with the same name. For example:

enum E1 { Red };
enum E2 { Red }; // error

• The name of an enumerator exists in the enclosing scope, which can cause surprising results. For example:

namespace NS1 {
 enum Color { Red, Orange, Yellow, Green, Blue, Violet };
};
namespace NS2 {
 enum Alert { Green, Yellow, Red };
};
using namespace NS1;
NS2::Alert a = NS2::Green;
bool armWeapons = ( a >= Yellow ); // ok; oops

The current workaround is not to use the enum and instead write a class wrapper (as in §2.1).

I guess similar pitfalls can occur when modules are used instead of C++ namespace above. In that case, we may need a “workaround” to separately define every enum in separate modules (to avoid name collision) and use xxx, only: <enum> to import only one enum into the local scope.

I haven’t read the relevant docs (linked in the above posts) yet so my understanding may be wrong in many points, but If the issue is well-known from many other languages, why repeat the same issue from the beginning…? Is it not possible to just require qualifiers? (like color%red and alert%red in the case of the above example) (For possible concern, @sblionel)

1 Like
#9

All of the concerns raised thus far in this thread, especially the work by Miller, Sutter and Stroustrup toward C++, were communicated to J3 Fortran committee via emails back in 2018 and at meetings during 2019 but to no avail.

However, as things stand with the workings, the effective default stance is there is nothing really all that much to learn from these newer languages, from C++, C#, D, Julia, Python, Swift, Rust, etc. as far as Fortran should be concerned.

This is the case even as each and every one of these languages find greater and greater beneficial applications in scientific and technical programming, the supposed focus of Fortran.

An attitude most detrimental to productive practice of modern Fortran prevails. I personally think a lot of this is due to the tight / tiny budgets toward Fortran compilers at commercial vendors that leads to doing the smallest or the simplest of feature enhancements. But reality bites and it is the practitioners of Fortran who have to suffer. Simple does not always translate to what is good.

1 Like
#10

I remember that the following proposal (linked above) had been posted several times on forums etc

Use cases and formal requirements for enumeration types (2019-October-08)
(https://j3-fortran.org/doc/year/19/19-229.txt)

and also the “reply” (linked above also)

Simpler enumeration types specs and syntax (2021-March-02)
https://j3-fortran.org/doc/year/21/21-120r3.txt

The first sentence of the reply is

Over the last year it seems that our approach to “true enumeration types” has become too complicated, and unnecessarily so.

I partly share the feeling why it is considered “too complicated” (in short, the request seems too much at once). But looking at the first post of this thread (unscoped vs scoped), the final result seems really oversimplification and could lead to unrecoverable situations. This is also against the recent direction of modern Fortran, i.e., make the syntax more explicit and robust against possible errors.

#11

It was with papers 19-230r2 and 19-231r2 the specific comment about “too complicated” was made. So the sentiment applies even more strongly with 19-229 I suppose. But that’s a shame.

There are major. major concerns with such narrow line of thinking re: “too complicated”. And again, it comes back to “For whom Fortran?”

  • Is Fortran only meant for some individual coders who have essentially complete autonomy as to the kind of coding they intend to pursue with the “tools” of their interest? And many of whom have their own an ever sliding, ad hoc and discriminatory and inconsistent scale as to what is simple or “too complicated”, what they like or find acceptable, etc.?
  • or does Fortran has a wider, open tent?

Think for a moment: reliable programming toward any scientific or engineering aim is an extremely complicated exercise.

Also, advancing needs require advanced solutions. That was the very premise of FORTRAN with Backus and team at IBM early 1950s.

In contrast to Fortran’s rich legacy or where things are every programming language with advanced features now that are finding both acceptance as well as value in scientific and technical programming, paper 19-229 is nothing complicated, only detailed on one of the simplest features.
That circa 202X for a basic facility which will only be available around year 2030 or later, the very notion of going skittish and wimpy at the hint of detail and to settle instead for a half-baked facility that will only be of limited use really, really looks bad for Fortran.

I agree entirely on this.

#12

I pretty much agree with @FortranFan. I will point out that this has been discussed at length at the committee (if I remember correctly, I also advocated to keep the enumerators local, not global), and the main argument seems to be to keep things simple in order to get at least something in.

However, as pointed out in this thread, adding a feature that is the simplest possible might not lead to what we want in the long term and it will prohibit adding a feature that will do what we want, and it would be better to rather not do it at all, and wait until we can do it right. See here for more details: Cost of adding (any) new feature to the Fortran language, note that @FortranFan was slightly opposed there. :wink:

The solution in my opinion is to prototype this correctly in a compiler and take time to do this right. And get the corner cases ironed out, and then write a proposal. The other part of the solution is to refuse to standardize anything that does not have a prior compiler prototype. (That was part of my platform when I ran for the WG5 and later J3 leadership, but I did not get the job. If I decide to run again, I think this will be part of my platform again, as I think it has to be done.)

Finally I would mention that compilers do not need to follow the standard. In this particular case, it seems we can have a compiler option that would disable global use of enumerators, and introduce an extension to use it locally, and if the community prefers, we can have it even as the default. But since this will be in the standard, some codes will inevitably use it, so we also need to support what is in the standard, with some simple option that would do exactly what is in the standard.

3 Likes
#13

@certik I agree with many of your points here. Pragmatically, what is it we can do, specifically for enumeration type? I genuinely think this needs to either be removed to changed to class 2 names.

1 Like
#14

The easy solution would be to just implement a different feature in the open source compilers. The proprietary compilers probably won’t be updated for 10 years anyway, so if everyone using enums in fortran uses the better version that isn’t standard compatible, it would significantly discourage use of broken standard compatible versions.

#15

@zedthree go ahead and write this up as a paper that proposes a fix to the already “approved” enumerations in F2023. You can send it as a PR against GitHub - j3-fortran/fortran_proposals: Proposals for the Fortran Standard Committee, and we can iterate on it there. Then we can submit it to the committee for the next meeting.

I just want to be frank and share that I think the chance is low it can succeed, but that is the process. All you need is to convince enough committee members that your fix is better. In order to even have a discussion, I suggest you write a paper how you think it should be done. If you have time, you can help us prototype this in LFortran, I am happy to help there also. Your paper can serve other compilers as an idea for an alternate implementation.

#16

@certik Thanks! I guess this would ideally need to be done before the July 18th meeting?

1 Like
#17

@FortranFan thank you for the insights and for your efforts towards minimizing the use of magic numbers in fortran applications. FWIW I’m happy to sign your petition should you go forward with it.

Fortran enumerators, as currently proposed, is a special case of the more general concept of Sum Data Types in type theory (the mathematics behind types in programming languages). See for example Algebraic data type - Wikipedia for an introduction.

Historically this was a concept only seen in functional programming languages. Lately it has become a feature most take for granted in recent not strictly functional programming languages as well:

Many “old timers” still under active development also seems to be catching up:

Given that the Fortran committee has been working on enumeration types lately I find it very odd, perhaps even worrying, that they are either unaware or totally ignorant of the advances on the topic in other programming languages. Note that the usual “competitors” to Fortran like Julia and C++ are a part of that list.

If anyone is interested in what sum types can do for us more than reducing the use of magic numbers, I’ll highly reccomend any of Scott Wlaschin talks. For example this section is a very practical introduction to the subject.

4 Likes
#18

Yes, it should be submitted for the July 18th meeting, so you should submit it to the github repository I linked above as soon as you can, so that we can iterate on it as a community to create a strong proposal.

1 Like
#19

@zedthree, and in addition to what @certik wrote, the paper should be uploaded to J3 a few weeks before the meeting, to give enough time to people to read and digest it, so, ideally early July.

1 Like
#20

I’ve made a PR. Suggestions and comments very much appreciated. It’s a rough first draft, but I have very little free time for the next month or so, so it would be good to get eyes on it now.

4 Likes
#21

@zedthree Your paper sounds very convincing to me. Granted I have no clue about the Fortran standard process, that might not mean a lot…

Exhaustive select statements fall under the same category in that it would be very difficult/impossible to add in a later revision (one would have to invent a new syntax). Personally I think that is an incredibly important feature, but I wonder if anyone else does so?

Of the languages @zedthree list in the paper, the following do require exhaustive matching:

  • C++ (when using std::variant)
  • Java (with the new pattern matching syntax)
  • Rust (always)
  • Switft (always)
  • TypeScript (though only through separate tooling)
  • Golang (though only through separate tooling)
  • Python (though only through separate tooling)

The following languages don’t require exhaustive matching:

  • C#
  • D
  • PHP

The following languages, I’m not sure about:

  • Ada
  • Raku
#22

@plevold I do completely agree, and I would really like to see exhaustive matching in the standard, but this is something that you could completely emulate with something like -Wexhaustive-select -Werror compiler flags. It would definitely be better to have it in the language though. I’d be happy to help if you want to add this to my proposal, but I’m afraid I have very little time to do so myself at the moment!

1 Like
#23

Thanks, @zedthree. I’m quite short on time these days as well. I’ll see if I’m able to write something that maybe could be included in your paper.

#24

The new Fortran Saga?