From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Sun Jun 12 01:37:30 2022 Return-Path: X-Original-To: sc22wg5-dom9 Delivered-To: sc22wg5-dom9@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 27A7E358CE1; Sun, 12 Jun 2022 01:37:30 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from sonic308-13.consmr.mail.ne1.yahoo.com (sonic308-13.consmr.mail.ne1.yahoo.com [66.163.187.36]) by www.open-std.org (Postfix) with ESMTP id 7D26E358CCB for ; Sun, 12 Jun 2022 01:37:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1654990647; bh=a/Ve6u+fW7THk7MQJUItvcguJl9+dhXm5S3BPikV4+Y=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From:Subject:Reply-To; b=SXRjVx1S/+8LykWPa0Nir9V2LrfllJSLSCUwj9zA4afXHXy5qmFm3ml5/o6iwC8qOKzDLGC281dgZcU21RTZpDYtXdLPkeXOVf1eXdHsUcmI3LJKAsiTI2HJJNsTkJn+l0lAsjR05ZYSjp2CHdekQ+xwh12bla6R0rwcRUfhwjkD9CX0J/aH6RYd8829BGd7p5qbl8hecHij9qJdOFuudayPrTmvjDD+thITSC4S4H1uNERq9CvciRPnyXc7UTRzgXNC7dXUgLUwhNkuiQfVMbhOkPyKaFtBIFzTtALVN0RGmHtMSHwFtp5kLnIkln7yQSHpdOzClu25tkbz7KjAvw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654990647; bh=k3zuxvRHzkWsrAcIH2AOOVC/8N2gn5JGZPtdSz/jTFo=; h=X-Sonic-MF:Subject:From:To:Date:From:Subject; b=PgUmG4XgJ4MOVg8uDWiH92wfLdDi7aHi7P8rcbLI/6EHra902lveH/dglh9vzWUUietN4rOl3ohlzPsakPvIIkaqPLf7+W0rXHz0nf+V8buSW27936Kw8aE1bHZrwvDBnxFBngt1dbttdTVoS/K5dwIL0NAeDxS5mW0G1eBZ9B2LwaQZ/yU9nw5DpwOdibIaZro7n3l/Ys2MXawr8wX5BG6crdeQFNJNp8K0wP/2xA0NQgw7UGZEFHQ6ZuxwLQbiZYUdPD8vy0AkqFTz0wCI55TZL2jntlVFiO9B6GrW8Y1Ku1PQNVTpmuwTic+ooSRTp5g6/Jy+sdal68plcdnyXg== X-YMail-OSG: Ch2WQhAVM1md9d2E6JHZtWYOwZhJbPmIKLQ5RjZvdy.ASUdI6cauotcmfm2KisH hBEo4mWQh6kv_KdQWfxdV_2F8CJW7B6uXd6ffaY0qyFyE_NvC2nHa6mZdUY7OUH44pVypoPKtNL9 zB2M6lYlFgKnJEFdPnHiwTMpGDhNLDfNS3DZshH.PLxIfBFuPvRbDTAvyGbLtDN1ozeuyikgYjiW 1zamNxXHUs_54wfTzK5xN_v_Jd1CMKNDKCCcW1YbIS8G9.vpRlW.Qha.elCgBHiA0z7xFf34Dngo MmFXnzr_GI7twaDhy2mKKsM0y39gZ5tiejIeoitCZqNS.h28Dz6dEn4vpKIkyhEDYdbp.98A7zvK _hCOAzQjEo2q2RPdO6udjROVgX38Hx.za0za6ynOEv7dApR0gHkt4VWmZrM.NkHtAxiSX72zW6j2 UbrArJP14enLXraiUOUxxbuMHyhtmUGy4y3klr1NPydti7mA8U7ak7suyDsblSmYgdNqAh7FLqPR YSFlomjDcULueQFblGfHBJWKe0f4RIi65ntfmaxuiVQUsdBUjpIzA5vtdBEai9FMp9cFn4jWLC4k MBzgFu7b2Wpz1NGA7TNiMkTPRxjE8vDTLYBukGSYLe4lnorCJ2LAGUfTcP8MdFRExRaltTeo7XWG X4mxN6mzMusRJ37Hc2ftFtcxM2DwlHrObkpfVLmQ9MCZVfr3TBEh45aYKDbvEmuDmxs1giXhERmN CHv0yxpOTFrvCJiGYIEFG7HBZFX58x37Ls2nmizGJcqkjIr1QUNXuxRC1oxgqHAQYoAV3qS4HWck bDKhQOOtC84hIbw5Y7O_cOUc60_fsLEMhEqGL7uACOvUYWWa08JABTgpC9jL1cuoVYfPKC7sl57B DtsDft69tKrIITD88_KS4wHUgVeqYnp6Ey9a3rh.RWA4pt0G6rxJAk01f2T07URwRBVCNJgKB4KA 6TdBVuHTI.O6vyR4aRJDF7bCbrDEXykmaIPKJ.T2Orc1pet9_fP9T.UGSlDeyI6ltNqaCa.zZf5P 34gI8MJ0enAhiAZn4.aJwWiBBv5jtMgs63OtWF90K.2hSfa.oUcEwhWuXdUGmUlP3yeiRagvO2s5 3CVtWSlTEsa6.4mZjJO.C_iIOloeHXEQzfTbukkswExD.eDXMS0aqpR1hK7DORZqk9qTxAD99lkt gZZzwIRhohLZLhxkwV1FLgKyPYOzYY5LWp139DyCCyAmXiMrXTcSPMPjJIAc1qVfi7JE_ELNuxEB I7sEyhwxBZkU17attts6kHCyy1hk0YHumQMOfbgAUQTNMl7ZOCUBoclyWImPMf0xQPoLtIUvSgvi jXwwcwcoDKSNQWjuJ2vCOIdKwaGgLhqKQPdZ65CvCb2b0zPjre3mWkhN6mP._acPbJxXsvJoZUdo kV3Ao606EPy.N5vMvBqpTqSv6eNMkW_3p49S0bpSS0zSVyW8.CWJqQUGfc2xTDnL2khC75JAsarb JrWkmcYZyXdcOPp0GC.WYTHK5IxYcl6Avdr38w5tDOZ1sG9PzZE951PHz0CpQWjjsUxgAIMvuyka VzElJ4nian2ryDtb9m1bous77EgL5jUExGMOkB4myonAUssrJXgBJil_pTeP82q268y5A3NxE9I9 2RWL_EzF7Qy_fCrTQASf0seeeGuyj3l9fxdGDSws985vC0X9BIHrLXmR5cAoCZ_9UFovL9lrINc. O407ImKSF.FTNcl1ctNAn_sbSbnFKAFEo51ej2ixl0vM0sbMbw1Yd0OAYt1fpFlz30OCfNRXmuxo czPEm.4PGETucus_Wd1l6BJMO1XCvSYcBsXJ49Hx0dubclJ7s4QNKemINMqS6lWL_NkbyjGEaQLr lxlnSOS8z3gRonKCd0dDx3oWlo7IZpcvMyhRwMKy6vsP5JoVjSVJjs_yYQGBAlzlGBQ_7ctJJYiD qLw3d3wTd9EYrIeO4o0L2yKXflsVdEOFI490CCTgCn3DBRK0Fkbthu8_rz.Q_moAsbDrNNkMZtAa D5GKbe_tPBUwq_vDrySAI3LV7P9k3wc3K8PERUB_kt3z_j4ZL18ptb59JkInroUAzS_5h38R2np2 JkH63ADUdRXgJMcQcsHdev1LPhu3sCMuZuq3Bnuicjytn.bXz0vep1_69miejHae7OCPL6HnMezw mdbK4eYJRCp_RpxRN2xADmzHn4HCKNhntblYvRyy1IMSjj1CW4Ujs.gKw71rWHjLh9m5a7.VC9P3 jtLbhbknAjpWrMlyliS.84B6xecW_wuTI6HAejM5kdT8Llw9PeQHGoqSVO80fd0b.1Yem3RIy9oJ F0GMWnyBGmzJY6OXKi3GT7LQZyD2roL.n8mI_Ze.eAj8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Sat, 11 Jun 2022 23:37:27 +0000 Received: by hermes--canary-production-ne1-799d7bd497-fg7z7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b80d3c35aaa1bf27721631b4986a9663; Sat, 11 Jun 2022 23:37:22 +0000 (UTC) Message-ID: <528bb9d20c5281a3e5edee7c2dc6d61f01938b38.camel@sbcglobal.net> Subject: Re: [J3] [SC22WG5.6396] Request for deletion of "US 21, part 1. Enumeration types" from Fortran 202X From: Van Snyder To: General J3 interest list , WG5 List Cc: Vipul Parekh , fortran standards email list for J3 Date: Sat, 11 Jun 2022 16:37:21 -0700 In-Reply-To: <20220611230237.0960F358CE1@www.open-std.org> References: <20220611230237.0960F358CE1@www.open-std.org> Content-Type: multipart/alternative; boundary="=-YODgmlhlzB+vHlUpImnn" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 X-Mailer: WebService/1.1.20280 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Sender: owner-sc22wg5@open-std.org Precedence: bulk --=-YODgmlhlzB+vHlUpImnn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Sat, 2022-06-11 at 19:02 -0400, Vipul Parekh via J3 wrote: > Dear Representatives of National Body Members of WG5, > > Please consider directing J3 to delete the edits associated with the > feature labeled "US 21, part 1. Enumeration types" [1] from the > Committee Draft revision 22-007r2 and also the eventual submission > with ISO and IEC toward the official publication corresponding to > Fortran 202X. > > Not only does the semantics associated with said "Enumeration Types" > feature fall short of meeting several of the crucial use cases for > this facility, the current design also makes it impossible, nearly if > not entirely, to extend this feature satisfactorily in a future > revision of the standard.  Of particular concern is the consideration > of each enumerator name in the definition of an enumeration type as a > Class(1) identifier. > > Please provide guidance as to the avenue and form for a formal > petition should that be seen as necessary for consideration of this > request. > > Most Sincerely, > Vipul S. Parekh > parekhvs@gmail.com > > [1] ISO/IEC JTC1/SC22/WG5 N2194, "The new features of Fortran 202x", > John Reid, March 21, 2022 I don't think it's necessary or useful to delete Enumeration Types. I also don't like that enumerators are class-one names. But that requirement can be changed in the future without invalidating any programs that conform to the requirements as presently written. One avenue of future extension is an additional class of names, consisting of enumerators. The rules could be something like "If enumerators of different enumeration types, having the same identifier, appear in the same scoping unit, they shall not appear except as arguments to the constructors of their respective types." This doesn't solve the problem of defining two types in the same module, having enumerators with the same names, and then trying to access an enumerator of only one of the types by USE association. But that problem is a minor problem, and can be solved in many situations by defining the types in different modules. The alternative, which would indeed require to remove the feature and re-design it, would be to require enumerators always to be qualified by their type names, probably using percent-sign notation. That is an ugly solution. Ada does not have this problem with enumerators. It considers enumerators to be zero-argument constant generic functions. A processor works out the type of an enumerator by applying its usual generic resolution ruiles, which take function result types into consideration. This has worked since before the first Ada standard. Fortran committees have resisted adding function result types to generic resolution rules, even though that part of the generic resolution problem was solved more than forty years ago. If Fortran's generic resolution rules were to be augmented to take function result types into consideration, it would not be necessary to qualify an enumerator with its type name, either always or only when enumerators of different types, having the same identifier, appear within the same scoping unit. Other problems would be solved at the same time. --=-YODgmlhlzB+vHlUpImnn Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
On Sat, 2022-06-11 at 19:02 -0400, Vipul Pare= kh via J3 wrote:
Dear Repr= esentatives of National Body Members of WG5,

Please consider direct= ing J3 to delete the edits associated with the feature labeled "US 21, part= 1. Enumeration types" [1] from the Committee Draft revision 22-007r2 and a= lso the eventual submission with ISO and IEC toward the official publicatio= n corresponding to Fortran 202X.

Not only does the semantics = associated with said "Enumeration Types" feature fall short of meeting seve= ral of the crucial use cases for this facility, the current design also mak= es it impossible, nearly if not entirely, to extend this feature satisfacto= rily in a future revision of the standard.  Of particular concern is t= he consideration of each enumerator name in the definition of an enumeratio= n type as a Class(1) identifier.

Please provide guidance as t= o the avenue and form for a formal petition should that be seen as necessar= y for consideration of this request.

Most Sincerely,
Vipul= S. Parekh
parekhvs@gmail.com<= /div>

[1] ISO/IEC JTC1/SC22/WG5 N2194, "The new features of Fortran= 202x", John Reid, March 21, 2022

I don't think it's necessary or useful to delete Enumeration Types. = I also don't like that enumerators are class-one names. But that requiremen= t can be changed in the future without invalidating any programs that confo= rm to the requirements as presently written.

One a= venue of future extension is an additional class of names, consisting of en= umerators. The rules could be something like "If enumerators of different e= numeration types, having the same identifier, appear in the same scoping un= it, they shall not appear except as arguments to the constructors of their = respective types."

This doesn't solve the problem = of defining two types in the same module, having enumerators with the same = names, and then trying to access an enumerator of only one of the types by = USE association. But that problem is a minor problem, and can be solved in = many situations by defining the types in different modules.

<= /div>
The alternative, which would indeed require to remove the feature= and re-design it, would be to require enumerators always to be qualified b= y their type names, probably using percent-sign notation. That is an ugly s= olution.

Ada does not have this problem with enume= rators. It considers enumerators to be zero-argument constant generic funct= ions. A processor works out the type of an enumerator by applying its usual= generic resolution ruiles, which take function result types into considera= tion. This has worked since before the first Ada standard. Fortran committe= es have resisted adding function result types to generic resolution rules, = even though that part of the generic resolution problem was solved more tha= n forty years ago. If Fortran's generic resolution rules were to be augment= ed to take function result types into consideration, it would not be necess= ary to qualify an enumerator with its type name, either always or only when= enumerators of different types, having the same identifier, appear within = the same scoping unit. Other problems would be solved at the same time.

--=-YODgmlhlzB+vHlUpImnn--