From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Thu Apr 10 04:15:36 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 06A45356976; Thu, 10 Apr 2025 04:15:36 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 398 seconds by postgrey-1.34 at www5.open-std.org; Thu, 10 Apr 2025 04:15:34 CEST Received: from nag-j.co.jp (bvdeuz19.secure.ne.jp [180.222.80.19]) by www.open-std.org (Postfix) with SMTP id 3EC78356652 for ; Thu, 10 Apr 2025 04:15:33 +0200 (CEST) Received: (qmail 69520 invoked from network); 10 Apr 2025 11:08:52 +0900 Received: from unknown (HELO Maru10) (218.42.159.105) by 0 with SMTP; 10 Apr 2025 11:08:52 +0900 From: "Malcolm Cohen" To: "'sc22wg5'" References: <92b8beb0b6209af89fbf0f413146dc17c87beb72.camel.ref@sbcglobal.net> <20250409230443.AF993356936@www.open-std.org> In-Reply-To: <20250409230443.AF993356936@www.open-std.org> Subject: =?utf-8?Q?RE:_=5Bukfortran=5D__=5BSC22WG5.6679=5D_?= =?utf-8?Q?I_don't_get_a_vote=2C_but_=E2=80=A6?= Date: Thu, 10 Apr 2025 11:08:52 +0900 Message-ID: <003401dba9bd$81b138f0$8513aad0$@nag-j.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01DBAA08.F198E0F0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJplxeujoKDXTME7tr1Y7UxWP2EugFwJwWasnTIkNA= Content-Language: ja Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. ------=_NextPart_000_0035_01DBAA08.F198E0F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Van, =20 N2217 is from 2023. There are J3 papers proposing requirements, = specifications, and syntax. Even a draft edits paper. =20 1. I think it was because it called an intrinsic function that requires = an argument to be an array. That needs the scalar case to be separate. = There have been suggestions to loosen some of these requirements, but = that degrades error detection, so there is a tradeoff. 2. Yes, generic procedures cannot be used as actual arguments. This has = always been the case. It is usually possible to do things differently, = without deleterious effects on code size or readability. So far we have = not found a compelling reason to invent another way to work around this. = As you surmise, having auto-generic procedures might tip the balance on = this. Or might not. F2028 is already overly ambitious, in my opinion, so = realistically we=E2=80=99d be talking F203z or later for any such = feature. =20 Cheers, --=20 ..............Malcolm Cohen, NAG Oxford/Tokyo. =20 From: owner-sc22wg5@open-std.org On Behalf = Of Van Snyder Sent: Thursday, April 10, 2025 8:05 AM To: sc22wg5 Subject: [ukfortran] [SC22WG5.6679] I don't get a vote, but =E2=80=A6 =20 I'm J3 emeritus so I don't get an official vote, but I have a few minor = comments on N2217: =20 1. Why is a separate specific procedure exemplar needed for RANK(0) and = RANK(1:15)? Could RANK(0:15) be used? =20 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. If their identifiers are accessible, they = 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. =20 I amended the 04-391r1 scheme in a later "wishlist" paper that I might = or might not have submitted to the J3 archive: =20 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. =20 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. =20 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. =20 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 =20 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 with 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. =20 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. ------=_NextPart_000_0035_01DBAA08.F198E0F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Van,

 

N2217 is = from 2023. There are J3 papers proposing requirements, specifications, = and syntax. Even a draft edits paper.

 

  1. I think it = was because it called an intrinsic function that requires an argument to = be an array. That needs the scalar case to be separate. There have been = suggestions to loosen some of these requirements, but that degrades = error detection, so there is a tradeoff.
  2. Yes, generic = procedures cannot be used as actual arguments. This has always been the = case. It is usually possible to do things differently, without = deleterious effects on code size or readability. So far we have not = found a compelling reason to invent another way to work around this. As = you surmise, having auto-generic procedures might tip the balance on = this. Or might not. F2028 is already overly ambitious, in my opinion, so = realistically we=E2=80=99d be talking F203z or later for any such = feature.

 

Cheers,<= /o:p>

-- =

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

 

From:<= /b> = owner-sc22wg5@open-std.org <owner-sc22wg5@open-std.org> On = Behalf Of Van Snyder
Sent: Thursday, April 10, 2025 8:05 = AM
To: sc22wg5 <sc22wg5@open-std.org>
Subject: = [ukfortran] [SC22WG5.6679] I don't get a vote, but = =E2=80=A6

 

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.  If = their identifiers are accessible, they 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 = with 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.

------=_NextPart_000_0035_01DBAA08.F198E0F0--