An alternate take on Enumeration Types: an approach seeking to help Fortranners avoid "magic" values in code

[FortranFan]

I submitted this paper 19-229 at the recent J3 meeting in Las Vegas (October 14 - 18, 2019) but it was ignored on account of being inconsistent with the decision(s) at the joint WG5/J3 meeting in Tokyo earlier in August. I was motivated to submit 19-229 based on the needs, use cases, and requirements (as explained below) I foresee users will want in Fortran towards their applications in scientific and technical computing and which were either not tabled during the discussion at Tokyo or they were addressed rather inadequately.

Take the IEEE spectrum rankings for most popular languages now and review the facilities toward enumerations in any of the top ones e.g., Swift as described here. Should Fortranners want to start expressing their coding constructs in Fortran as clearly and succinctly as possible using any of these other options available to engineers and scientists and where type-safety is to be valued and "magic" values are to be avoided (I'll provide more information toward this later on in the comments section), they will seek a comprehensive facility similar to what is offered by, say, Swift language. However what is on the anvil for Fortran 202X is a poor shadow of this, so the situation is of great concern to me.

From the paper:

Introduction

This paper, while trying to build upon the benefits and features of enumeration types known generally and also stated in the above referenced papers, attempts to document the use-cases and example code snippets derived from extensive use of enumeration types with other programming languages that are currently used indescribably more widely than Fortran in chemical processing and manufacturing industry even in engineering and scientific technical/numerical domains and applications. "No magic numbers in code" and type-safe programming are among the most basic aspects of the good coding practices (GCP) sought after by managers and technical leads toward computing in such industry. But even in these aspects, Fortran falls short relative to other top programming languages today and this gap compounds the reasons why Fortran does not get considered for any large and/or new application developments. It is therefore critically important the facility toward enumeration types in Fortran be developed comprehensively to support a wide spectrum of beneficial use cases in scientific and technical programming. The section below strives to list all the cases from industrial experience and to extract feature requirements from these examples so that the formal specifications toward this facility can be pursued.

[certik]

@FortranFan Thanks a lot for opening a discussion regarding this. I was on the Data subcommittee where your paper got discussed --- if I remember well, we went over your paper and tried to extract useful things that were not part of the other proposal in #11. The issue was that there was apparently already an effort from Tokyo, as documented in #11, and your effort was not coordinated with them. Had we used github already, we would know about these efforts and could coordinate better.

By looking at the use cases and motivation at #11, I am not convinced that they have done due diligence to explore how other languages do that, nor many examples how enumeration is actually used in codes.

Either way, let's start over, and discuss the use cases, then try to formulate what features the community would like and then try to create a solid proposal for the next meeting.

I see several issues that the committee was trying to figure out, and we need to have good arguments why yes, or why not:

• Should you be able to assign values to enumerators? If so, only integers, or other things such as strings, floats, etc., per examples in 19-229.

• Should you be allowed to set some enumerators as private?

• Should enumerators be class 1 names?

• Should next / prev functions be added? (Swift does not seem to have it, neither does C or C++, as far as I know)

• There was also a lot of discussion about syntax, some of which happened at the J3 mailinglist

Are there other questions that we do not have agreement on?

I would start thoroughly discussing these and find an agreement on these questions first, or at least list pros and cons. I noticed suggestions at the J3 mailinglist for not doing any work on this until our next meeting, when somehow it will be time for action. I think we should do the opposite -- we should try to do as much work as we can remotely, so that when we meet the next time, we either have a solid proposal, or solid lists of pros and cons, and we can vote what we want to do.

[rweed]

I agree that the committee needs to do a more extensive review of how enumerators are used in other languages and even more thought on how they would be used in Fortran codes. Given Fortrans traditional focus on scientific and engineering programming, some of the use cases in other languages might not be appropriate. I currently use them extensively as a convienient way of defining parameters for SELECT CASE selectors since I find that easier than creating individual INTEGER, PARAMETER values for each one. Most of the time you care less about what the actual value is than is it different from other values. As a first step to defining a full enumerator cabability I would do the following.

1. Remove the BIND(C) requirement since it makes no sense if you aren't doing C interop.

2. If its decided that more intrinsic data types should be supported just add the ability to set the KIND with the enum statement, ie ENUM(KIND=INT64) or ENUM(KIND=REAL32)

3. Allow enumerators to be named (Cray did this in its pre F2003 compilers and might still allow it as an extension) ie
   ENUM(KIND=REA64) :: PiValues
   Enumerator :: PI=3.1415---, TWOPI=2*PI
   End Enumerator

4. Add capability to change/set the default increment

   ENUM(KIND=REAL32, INCREMENT=3.0_REAL32) :: threeValues
   Enumerator :: THREE=3.0_REAL32, SIX, NINE, TWELVE
   END ENUM

This addresses what I consider the first and most important (for me at least) of use case for enumerators. Ie as a more convienient way of defining parameters without resorting to individual PARAMETER statements for each value

[FortranFan]

@rweed wrote:

.. Given Fortrans traditional focus on scientific and engineering programming, some of the use cases in other languages might not be appropriate. ..

Re: other languages and what is appropriate or not, consider J3 Fortran paper 19-216r1 discussed at the Tokyo meeting which was the basis for crucial decision(s) by the WG5 body, decision(s) that might constrain and limit what will get introduced to Fortran 202X. That paper mentions 4 other programming languages in its Introduction starting with C; it also states, "Pascal, Modula-2, Ada, ... have proper enumeration types, and enumerators of those types, because they are useful." and elsewhere in WG5/J3 documents it has been mentioned Fortran 202X shall have "proper enumeration types".

Now, note in connection with Ada being mentioned in 19-216r1: one of the features under consideration toward enumeration types in Fortran is %NEXT ( or ..%NEXT()) ) and %PREV ( or ..%PREV() ) to loop over enumerators in a type instance. This has similarities with facilities in Ada such as 'SUCC and 'PRED in Ada: see here. Few other languages support such as a facility with their enumeration types.

I then ask:

• if certain languages such as C or Ada and their use cases are acceptable for consideration of feature design in Fortran, even for year 2022/2023 (!!), why not other languages? Why not look wider say toward IEEE Spectrum and its current rankings toward the most widely used languages? IEEE is, after all, among the largest organizations for engineers and applied scientists, if not THE biggest. Also, if one is learning from other languages and their applications, why ignore recent and modern advancements? C language is in "maintenance mode", Ada the same since 2012; do Pascal and Modula-2 need to be discussed?

• Now, also note Ada (dating even before the Ada-95 standard) supported the specification of values of enumerators and also character literals and boolean types in enumerations: see here and here. Note my paper (19-229) does make use cases for character literals and logical types kinda like Ada in addition to integer and floating-point types which are supported, by the way, in Swift language. However the disappointing situation is the Fortran proposal toward Fortran 202X will likely NOT support any of these aspects: if something does make it in, it'll likely be along the lines of following:

enum :: CALC_SPEC
   enumerator :: FUNC
   enumerator :: FIRST_DERIV
   enumerator :: SECOND_DERIV ! value = 4 (say) will not be allowed; Ada does
   ..
end enum

• So if Ada is going to be used as a basis of one feature (e.g.,NEXT, PREV as explained above), then why not other aspects, particularly when these other aspects can be seen to be supported by other top lanaguages on the IEEE Spectrum and ALSO when I see there are modern applications in technical computing in industry that actually employ these enumeration type facilities to develop code that read so well and which are easier to maintain and improve over time as well?

• So then, who really gets to decide use case X based on Ada is ok but use case Y from modern C++ or Java or C#, or use case X from Swift language are NOT acceptable?

[FortranFan]

@certik wrote:

..
I would start thoroughly discussing these and find an agreement on these questions first, or at least list pros and cons. I noticed suggestions at the J3 mailinglist for not doing any work on this until our next meeting, when somehow it will be time for action. I think we should do the opposite -- we should try to do as much work as we can remotely, so that when we meet the next time, we either have a solid proposal, or solid lists of pros and cons, and we can vote what we want to do.

Thank you @certik , your proposed path forward makes perfect sense. Issue threads such as this and the comments therein can hopefully provide the background material for all interested Fortranners to provide better input and develop better proposals and make better decisions.

[certik]

@FortranFan I agree with you that the justification based on Ada is not consistent with the idea to look at all modern highly used languages (I like your IEEE list) and see what they do and then choose what's best for Fortran. It seems that Ada is cherry-picked, and even that inconsistently, as you pointed out.

Note that Ada seems to have succ and pred functions that work on other types such as integer (per "'Succ and 'Pred work with any scalar type" from here and per "X'Succ(Y) is an Ada attribute where X is any discrete type and Y is a value of that type" from here). As such it makes perfect sense to extend those to enumeration type also.

In case of Fortran, we do not have succ and prev and so it does not make sense to somehow for Enumeration to have those. The closest that Fortran has is nearest.

So given that, the "natural" position is not to have first, last, succ and pred. If we want to have those, I would like to hear very good arguments for that.

In a similar way, I would like to tackle all the other questions.

[FortranFan]

@certik and all interested in Enumerations in Fortran, please take a look at this PEP for Python.

With paper 19-229 mentioned above, my hope was to provide the background and use cases that would help the Fortran committee develop a comprehensive facility that is consistent with the legacy, semantics, and syntax of Fortran, similar to what one notices the Python org did with their PEP 435 back in year 2013.

If one looks at Python PEP, one can effectively feel the care and concern and the motivation to really help the practitioners of Python do better with their code.

And consider the basic aspect of enum type in Python with the ability of assign value to an enumeration member (aka enumerator per current papers on Fortran):

>>> from enum import Enum
>>> class Color(Enum):
...     red = 1
...     green = 2
...     blue = 3

This is something you will notice with almost all the languages seeing any significant use in numerical computing, whether it be Ada (embedded and real-time systems e.g., avionics and aerospace applications), C++, C#, Java, etc.

What is on the horizon for Fortran plans to deny this basic ability to assign any values in Fortran enumerations (they can only be auto-assigned starting with unity in the order of enumerators) which, right off the bat, invalidates so many use cases based on existing codebases toward engineering and technical computing I have seen.

For a language like Fortran which essentially disallows any named constants or variables to come into existence with an automatic value (without negative consequences), it appears entirely orthogonal to existing semantics what is being considered with the current plan for enumeration type. This is highly bothersome to me.