From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Thu Apr 10 01:04:43 2025 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 76655356976; Thu, 10 Apr 2025 01:04:43 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from sonic313-12.consmr.mail.ne1.yahoo.com (sonic313-12.consmr.mail.ne1.yahoo.com [66.163.185.35]) by www.open-std.org (Postfix) with ESMTP id AE80F356820 for ; Thu, 10 Apr 2025 01:04:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1744239879; bh=C3yusxv8kiAsu+VBvoZkuoKnzN4V7pfoPlMkZdVUQVo=; h=Subject:From:To:Date:References:From:Subject:Reply-To; b=eZrV3G9D95E9LpZs6bP5d/hBzIYtVzRpgqyc8AIU9E/LIVlMZD0xlfmfCUuAyv//mJ7x9ZY41YbIlewtwW0utEv8rl8dMYpUg0b1jcgdSnGejttNdsjCERcdj85spRbkEbPjzvaDx6KkOgVvQKqwZKC5jicMaKKn/lt5UBIohOMgAvsqxlNdmaPihuTG4YKGNzo16B1HttS2a0DggABI5mAEnSBOk3um9XZsAkuMF/Ro3ZzVarAnIrtvOmjIrckEKOSwcrYXEJTGBOf7c+vdTcmUxE6KjeQ7vWAEYUDDcb1bEE+ps7207upH/Js6CIZ8Jh/xj4+u4zWPTJlmrHsJiQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1744239879; bh=EPzqLGbiZLfnQw9YDfb+uW1qVuWdY+rmsxCoXFrwjqC=; h=X-Sonic-MF:Subject:From:To:Date:From:Subject; b=ISugXWOZliqhwRx/iMdCUswbC5wDgtfV1lQ1JWT9mpLYQUPgm2X9Yyw9cUvqon4/MCBtkiGfdjzwOl4fXyUah1rwJiJG/hYnszpZOjRdFJig8ENZvyu2xOf0J01xRYPCz/xMOV2u3OzMY6T7Pcsz/qls8H3OGIuW4F/sNR9gVRV1b+zvnnA+GtBN/E+6SggH2YMv3l9bPNnXhR3c/SvD6ZNRZig9BEX5r8gRBg0Ppf8WTkKjusxgk9hkklBoDsO2qf9CLXY8YuO6EkvyoL3NN/JTuogIFeSs97/f10ZxquZronZYoRTRYuSWdYHUzgOgJpQXw2qljd+tnLF4jnnP/g== X-YMail-OSG: CAe.dGMVM1kLWbvodA3k_L0DcgJJq_Y5JMUWcBmW7xiRtNQvh4iwvFoHCnV2U11 ToJFY5E20ST2oKYY9AzR9L8qx7eO.1P6VfkU2EzlpfKSOzxpoSR8BhuCFD9PX6.z8pGp8V11KT2i zIKY.7hO.Jj2_y_Isdfr3Pl0FjLb94vdiii_aqrXtUrAzpSmhUZ7dlWCxpSeB35IBwdkyP2PmlBg seBfuDFhgSjVgeKU05n5n_TaRVQII_dMUlOzaIrlc68UtZgd.ZhgxsexkxmBkjBjmBgMJh2GGk3p rP4Iape.45ayMBIFws5LJzS3jMa8qDr1j.dDqTpvT3W9R0n1o6PZHCX7EzTqss_HQg6fipqrOIkj XYvdBkLSxcHSxyw5NHwOKEdvADiUtGfPcXSb0r0Db.v64lexw59rqMxnClk9lnsFdQleD_qAaocG 2s2KUsqKo74gNiz9Tt58fiyP_6D1aaDIGHuwgPX2uUuyTHSlsUfw4z5H5IamVFvOQIlY_qnYLrWf T4MpC0wSEhKBBNSCbOai1hqeVSOkhjWTEplJpzb0epOxuViCrGK.1wMAXzM5bynXIUslA3wwgp64 dhivDbJ9AlplFM7l8x7NuLPlB22IGrFbTM6YXuUUmfTDzL2q99qVYBmaOJWHzRnT_.ag9WaxV3fg _qqQKel_ykk_xCMrrcX0HOcSo3jUjv_I_Gl68sRbQC.mxMFZenE0rZHWT_rviwklS_GWCq8Oa_FA D6vV13jtbqbK5mKVHeFhRWYMaCn4jcuMmhFInvrf13tncfKitnA2T3zPmJxBji0wQoikVEe3gSid WUjjVO.yJ1._tMBgYaKHg4V5oJ18IUCud50N0Ihn2eCoIdhzTP2ZW5Kv2mvevMTD5p8vL.6OocGJ fr.lytiYBU2Q89VxGlWMsUWFoW8npubUVFmtLnDztjoQRaLBDrj.Y3ldRqLb_tCFjfo1Rx05arGb _iqTR2H8RNEqWgKH0BPj26Yx7iV1YOcbHo5EaRNFh7Kk0WHidmX6qzU398TNTyRNILyXahvyjXgc o3SJz1oX9vrNLwGIvmmDi5L.VCBDrIwwmaxpiuF.kgJXmcAY27kdP5Rn3owvh0ACIsME30eV1YQ8 CwUznxYqQtQF.qWOmY4xz_7mMu24OiX711gZCEde57zOs9C4LxDt0vzIm7zQGMjwKYveOQNT0Nfx GL7Ywo684XMvaX1bbbwHk9poy0TWUAZgevmbIQxYzoR00pdMGF1ScYjGnT9DjFzdREzmoNpK7fND VIN58NGRL8xxtcNwfK2NiDxzRDqm62Xut4LNvL.RfR_7VaIJfgFxDc6XM8BlY8szZAYjVvqtqKzO h427Hns0WsCu.Uoq.LqCSgNHjE4VJGze0POr8g.9CvB_sO75cEAXyb1vb0Ndh6yVZ.MpnGgpaxo. qPi1IIVBiBs.YeF3J5yVSqmxZ2S0gzljj.LwbkEfMEkomP0hNyPm5GDABNdctgoVBedffxnjSuPF MaPlwoJ6kacsxCKAWHOeziU5UG521hPATfsuZuHU7pIeQzdN1Zzl5Hi0MDC0jr.XEFjgArZ_pouY V3go4cR46urazpudLI_CMvGwWE6lmEWwL6VwRLl7PJYAKo4O4AkRsnHqBc8bBAaRF3iWLW5apRJM udZmt9YiiOVT8riuWb0sAHptOBiDt0D655rCKkKEwH0DkcDy4lHkXixwP7h6pifDVPJiBQPTz8SR 4VegZcvna3XGKzsej_IS8xaPNTnDQ30BcUm6OAy_seK8kxUEf3HOT8c0EycU2uV_OV2JzDph73Io gqe0Ldn3_gxeseHyoErqM9Q9AeQXabI.JSOF8o_UeYIga5HpEtFJpAYSUTohihZAvCWVi8wqyYfM .mtpLuSpxuSH65.9BaqCv7QbL01ZHSwt9WFVpxG6GuofuwIVLRvWgRvzrORDKZ7iu5oKenYkADSi Pcg1dUDbh_ke7LkjHOfXaNEphhZfNiIPKW3PO3Z77uO_JXoKMqrFC8tnYGpVHKBhwWnqkvb9.d70 czvfr5D7siwIKxMF42ag5wNrflAryv34LMZtX0_hk7.oLn1pP8Se39qm9CgRjOPYlurZm0SoDzJp Bp5YnlJB5Wr8P2KRd7rFFBbHj7Aeh_Zroh2qqLI6vzomn_E8u7wowRcRfoOK2vk87R8PDNAFLwcL mW__hWkvowuf05RXKkQE7g.wk3d0iY8b.1.BOuAI0VzhIWLv.SHg0geVow2axpRbXRHiY0xyhnbW sqUaougnA9RPQxGSter6wYzvmMHD07k3JzTc06QrbtY8wsgY4CS8v.aV7ypoYXHwhVDqBT3CoD3o rcG3qu5QpatfXHQVfChFN4mJGHR5Zt9K0xA-- X-Sonic-MF: X-Sonic-ID: 503dc5cd-5e6f-4b3b-b0ce-411169f39dc9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Wed, 9 Apr 2025 23:04:39 +0000 Received: by hermes--production-gq1-6f8bfcd964-g7jn2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 147be75c2f688487e08f7894a2e8ec36; Wed, 09 Apr 2025 23:04:34 +0000 (UTC) Message-ID: <92b8beb0b6209af89fbf0f413146dc17c87beb72.camel@sbcglobal.net> Subject: I don't get a vote, but =?UTF-8?Q?=E2=80=A6?= From: Van Snyder To: sc22wg5 Date: Wed, 09 Apr 2025 16:04:32 -0700 Content-Type: multipart/alternative; boundary="=-9UPyuKOxUJrKqBWaXnVu" User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 References: <92b8beb0b6209af89fbf0f413146dc17c87beb72.camel.ref@sbcglobal.net> X-Mailer: WebService/1.1.23665 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Sender: owner-sc22wg5@open-std.org Precedence: bulk --=-9UPyuKOxUJrKqBWaXnVu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm J3 emeritus so I don't get an official vote, but I have a few minor comments on N2217: 1. Why is a separate specific procedure exemplar needed for RANK(0) and RANK(1:15)? Could RANK(0:15) be used? 2. Generic procedures cannot be used as actual arguments. If one has a module written under the present system that contains numerous specific procedures and a generic identifier that glues them together, specific procedures have identifiers. =C2=A0If their identifiers are accessible, the= y can be used as actual arguments. In the proposal in N2217, the specific procedures do not have accessible identifier. A solution I mentioned in 04-391r1 is to provide a mechanism to compute the specific procedure from a generic identifier, at compile time, so it can be used as an actual argument. It would be even more useful in this context than it would have been in the existing scheme. I amended the 04-391r1 scheme in a later "wishlist" paper that I might or might not have submitted to the J3 archive: Rationale With care and diligence, one can develop a program so that related sets of variables, constants and function results are parameterized by a single kind type parameter. In order to change the kind of that set of entities, one need only change one named constant=E2=80= =99s definition =E2=80=94 almost: Generic procedures cannot be actual arguments or procedure pointer targets. Thus, if one needs to change the program, in addition to changing the single named constant definition, one needs to find all places where a specific procedure that operates on the entities in question is an actual argument or procedure pointer target, and manually edit those appearances. Alternatively, one needs to write a specific procedure, with arguments appropriately parame- terized, which in turn references the generic procedure, and pass that specific procedure as an actual argument. This is less onerous than before Fortran 2008, because of the ability to pass internal procedures as actual arguments. Nonetheless, it increases code bulk, which increases lifetime cost. It would be helpful to have a facility to resolve a generic name to a specific procedure without evaluating any arguments or invoking a procedure. Proposal Allow an actual procedure argument to be a generic identifier provided the referenced procedure has explicit interface, and the dummy argument corresponding to the procedure actual argument has explicit interface. Generic resolution of the actual argument to a specific procedure would be based upon characteristics of its associated dummy argument. Allow a procedure pointer target to be a generic identifier provided the procedure pointer has explicit interface. Generic resolution of the pointer target to a specific procedure would be based upon characteristics of the procedure pointer.Proposal Alternative proposal If an actual argument is generic-name, and an interface body with that name is accessible at the point the procedure is invoked, the procedure that is invoked shall have explicit interface. The dummy argument associated with a generic-name shall be a dummy procedure with ex- plicit interface. The specific procedure from the interface that is compatible with the dummy argument is associated with the dummy argument. If the dummy argument is a subroutine the generic-name shall identify an interface that provides a subroutine that is compatible with the dummy argument=E2=80=99s interface, and that subroutine is associated w= ith the dummy argument. If the dummy argument is a function the generic-name shall identify an interface that pro- vides a function that is compatible with the dummy argument=E2=80=99s interface, and that function is associated with the dummy argument. If a proc-target in a procedure pointer assignment statement is generic-name, and an interface body with that name is accessible at the point where procedure pointer assignment appears, the proc-pointer shall have explicit interface, the generic-name shall identify an interface that provides a specific procedure that is compatible with the pointer object=E2=80=99s interface, and the proc-pointer becomes associated with that specific subroutine or function. --=-9UPyuKOxUJrKqBWaXnVu Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I'm J3 emeritus so I don't get an official vo= te, but I have a few minor comments on N2217:

1. W= hy is a separate specific procedure exemplar needed for RANK(0) and RANK(1:= 15)? Could RANK(0:15) be used?

2. Generic procedur= es cannot be used as actual arguments. If one has a module written under th= e present system that contains numerous specific procedures and a generic i= dentifier that glues them together, specific procedures have identifiers. &= nbsp;If their identifiers are accessible, they can be used as actual argume= nts. In the proposal in N2217, the specific procedures do not have accessib= le identifier. A solution I mentioned in 04-391r1 is to provide a mechanism= to compute the specific procedure from a generic identifier, at compile ti= me, so it can be used as an actual argument. It would be even more useful i= n this context than it would have been in the existing scheme.
I amended the 04-391r1 scheme in a later "wishlist" paper that= I might or might not have submitted to the J3 archive:

Rationale
With care and diligence, one can develop a= program so that related sets of variables, constants
and functio= n results are parameterized by a single kind type parameter. In order to ch= ange the
kind of that set of entities, one need only change one n= amed constant=E2=80=99s definition =E2=80=94 almost:
Generic proc= edures cannot be actual arguments or procedure pointer targets. Thus, if on= e
needs to change the program, in addition to changing the single= named constant definition, one
needs to find all places where a = specific procedure that operates on the entities in question is
a= n actual argument or procedure pointer target, and manually edit those appe= arances.
Alternatively, one needs to write a specific procedure, = with arguments appropriately parame-
terized, which in turn refer= ences the generic procedure, and pass that specific procedure as an
actual argument. This is less onerous than before Fortran 2008, because = of the ability to pass
internal procedures as actual arguments. N= onetheless, it increases code bulk, which increases
lifetime cost= .

It would be helpful to have a facility to resolv= e a generic name to a specific procedure without
evaluating any a= rguments or invoking a procedure.

Proposal<= /div>
Allow an actual procedure argument to be a generic identifier pro= vided the referenced procedure
has explicit interface, and the du= mmy argument corresponding to the procedure actual argument
has e= xplicit interface. Generic resolution of the actual argument to a specific = procedure would
be based upon characteristics of its associated d= ummy argument.

Allow a procedure pointer target to= be a generic identifier provided the procedure pointer has
expli= cit interface. Generic resolution of the pointer target to a specific proce= dure would be
based upon characteristics of the procedure pointer= .Proposal

Alternative proposal
If= an actual argument is generic-name, and an interface body with that name i= s accessible at
the point the procedure is invoked, the procedure= that is invoked shall have explicit interface.
The dummy argumen= t associated with a generic-name shall be a dummy procedure with ex-
<= div>plicit interface. The specific procedure from the interface that is com= patible with the dummy
argument is associated with the dummy argu= ment. If the dummy argument is a subroutine
the generic-name shal= l identify an interface that provides a subroutine that is compatible with<= /div>
the dummy argument=E2=80=99s interface, and that subroutine is as= sociated with the dummy argument.
If the dummy argument is a func= tion the generic-name shall identify an interface that pro-
vides= a function that is compatible with the dummy argument=E2=80=99s interface,= and that function is
associated with the dummy argument.

If a proc-target in a procedure pointer assignment statem= ent is generic-name, and an interface
body with that name is acce= ssible at the point where procedure pointer assignment appears,
t= he proc-pointer shall have explicit interface, the generic-name shall ident= ify an interface that
provides a specific procedure that is compa= tible with the pointer object=E2=80=99s interface, and the
proc-p= ointer becomes associated with that specific subroutine or function.
<= div> --=-9UPyuKOxUJrKqBWaXnVu--