[J3] 21-120r2: Discussion on the feasibility of any future enhancement of Enumeration Type

Tue Mar 2 07:58:01 UTC 2021

Hi Vipul,

A type with gaps and duplicates is not an enumeration type. There’s no reasonable FIRST, LAST, NEXT or PREVIOUS of such a type.

A named constant array already provides the facility for an arbitrary list of named constants.

If you want a way of having a type that is a collection of named constants, you just need different syntax. Like, you suggested having a type-spec for the type of the constants. There is no problem with accommodating this in the future.

(I also question whether the limitation to intrinsic types for such a facility would be even close to acceptable. If they are not limited to intrinsic types, using type conversions to “get the value you wanted” is not a good solution anyway.)

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Vipul Parekh via J3
Sent: Tuesday, March 2, 2021 3:22 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Vipul Parekh <parekhvs at gmail.com>; Malcolm Cohen <malcolm at nag-j.co.jp>
Subject: Re: [J3] 21-120r2: Discussion on the feasibility of any future enhancement of Enumeration Type

Hi Malcolm,

Re:  Ondřej's question at the plenary today (Monday, March 1, 2021) as to feasibility of any future enhancement of Enumeration Type and where he mentioned me, can you please take a look at the scenario below?

Consider the 'w_value' example from 21-120r2:

Enumeration Type :: w_value
   Enumerator :: w1, w2, w3, w4, w5, wendsentinel
End Enumeration Type
Now consider 'Type(w_value) :: w = wendsentinel' and 'x = INT(w)'.  Paper 120-r2 suggests x will have the value of 6, correct?.
Now, say in the future (Fortran 202Y or later), an enhancement is proposed that seeks to allow a programmer to instead author a *Fortran-only* (i.e., no BIND(C)) enumeration type as shown below: you will note this is pertinent to Ondřej's question because he brought up my name and I have requested such facility in paper 19-229:
Enumeration Type :: w_value
   Enumerator :: w1=0, w2, w3, w4, w5, wendsentinel = 65535
End Enumeration Type
Here, please note the changes in 'w1' thru' 'w5' and with 'wendsentinel'.
Let us consider again 'Type(w_value) :: w = wendsentinel' and 'x = INT(w)'.
What will be the value of x in this second scenario?  If it remains as 6 or if it were to change be 65535, it will be rather confusing to programmers because why would a 'conversion' result in either of the values.  But now, if type conversion to INT were to be disallowed under the new circumstance, it too will be odd and confusing because Fortran 202X would have introduced it.
Owing to this problem, a future committee is highly unlikely to allow any changes that Ondřej was asking you about.
Hence the concern I mentioned at the plenary that the type conversion you include under point (b) under 2.2 Specifications in 21-120r2 pretty much closes the door on any revision along the lines of what I have been requesting .  And the chances a committee would consider a third feature toward what is commonly understood as 'enums' aka 'enumeration types' will be nil.
Instead of 'type conversion' in 21-120r2 using INT intrinsic, should a simple ORDINAL function be introduced that would permit 'x = ORDINAL(w)', there should be no confusion now or later, the value of 'x' will be the ordinal and in both the two scenarios I show above, 'x' can remain 6.
Thanks,
Vipul

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. Please see our  <https://www.nag.co.uk/content/privacy-notice> Privacy Notice for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210302/6286844b/attachment-0001.htm>