To: J3 J3/22-128 From: Tom Clune & generics subgroup Subject: Response to Comments on Generics Formal Requirements Date: 2022-February-26 Reference:22-123r1, 22-120r1, 22-120r2 The generics subgroup has considered the comments on generics formal requirements presented in 22-123r1, and where we agree, have included the updates in 22-120r2. This paper responds to the individual comments and explains why certain items were rejected by subgroup. (Text from 22-123r1 is indicated by indentation and "|".) | B. Named restrictions shall be provided. | | A less hand-wavy syntax is interface blocks and bodies for dummy | parameters. If a restriction applies to a dummy parameter type, it can | be expressed as a type-bound procedure. First, this comment is more about syntax than the requirement, and as such is premature. But more substantively, generics subgroup did consider this approach in our early deliberations. The main problem with re-using type-bound procedure syntax is that in many/most generics use cases the operations are not naturally tied to a single type. Indeed, when trying to write templates of maximal generality, cases where use of type-bound syntax is appropriate become quite rare. Subgroup is not strongly opposed to future extensions in this direction, but feel that we must first agree on the basic functionality. This comment also does not appear to recognize the intent of _named_ restrictions as a means of reuse. This is an aspect subgroup strongly supports. | C2. A template can define any of the following entities: | | Enumeration types (and their enumerators) should be on the list. | | Named constants should be on the list. Subgroup agrees and has amended the revised paper accordingly. This was simply an oversight. | D. A template dummy parameter must be one of the following | | Modules should be allowed. If a dummy parameter module is | accessed by use association, the ONLY clause should be required to | appear. Subgroup strongly disagrees with this as it would be difficult to incorporate alongside "strong concepts". For a vanilla USE statement, the template would not know any properties for imported entities until the time of instantiation unless significant restrictions were made. At a minimum only entities named in an ONLY clause would be permitted and even these would need to be re-declared (or restricted) to permit their use. | Templates should be allowed, along with a prohibition against a | template instantiating itself either directly or indirectly. This has the same problem as with module dummy parameters. How could this be allowed while preserving the notion of "strong concepts"? The template would know nothing about what the template would/could provide. Subgroup does agree that recursive instantiation of the same template is undesirable. | Within the type definition in the hand-wavy example, a declaration | of a component and a type-bound procedure part would be | illustrative. Discussion of that should specify that component | and type-bound procedure declarations within dummy paramater type | definitions are minimum requirements, not exclusive requirements, | and no order is implied. Because subgroup disagrees with that approach, an example along those lines is inappropriate. | Near the end, SUBROTUINE should be SUBROUTINE Fixed. | E. A template shall be instantiated .... | | It is necessary that an instantiation have a name. Accessing | things from it should be essentially the same as use association, | including ONLY and renaming. | If instantiating a template automatically makes its guts | accessible in the instantiating scope, name clashes could | result. So instantiation and use must be a two-step process: | | INSTANTIATE LOCAL_TMPL => TMPL(INTEGER(KIND=INT32)) | USE LOCAL_TMPL, only: My_Get => Get_Ith | As for use association, the "only" clause applies only to | identifiers. If "Get_Ith" needs other stuff from the instance, | that's OK, but the identifiers of those entities are not | available. | | Alternatively, ONLY and renaming should be allowed on the INSTANTIATE | statement. | | This might clash with item F. This detail is addressed in the subsequent paper of generics formal specifications. Our approach is to provide similar capability without the USE statement. One technical issue with the approach above is that USE statements would need to be permitted deeper in the specification section of program units. | F. Multiple instantiations of a given template with identical | template actual parameters define the same entities. | | Does this apply only within one scoping unit, or every scoping | unit in a program, or one file-system directory, or the entirety | of file systems on one computer, or the entire cloud, or ....? The program. An attempt at clarification has been made. | | G-K concerning RESTRICTIONS and REQUIRES | | Restrictions and requirements can be specified by interface blocks, | interface bodies, and other dummy parameter declarations. First, this comment is again mostly abount syntax, not the underlying requirement. Granted that the requirement is expressed in a manner that suggests syntax, but that was intended to _avoid_ confusion with existing INTERFACE features which are similar but do not quite align. But ... digressing a bit into the possibilities for syntax, subgroup disagrees with the comment above. We do of course hope to reuse some such syntax within RESTRICTION constructs, but the existing Fortran INTERFACE block is inadequate in at least 3 respects. 1. Existing INTERFACE blocks define a generic name and the use case here is for a collection of otherwise unrelated procedure interfaces. E.g., it may mix subroutines and functions, and these will not be in any way be invoked via the INTERFACE generic name. 2. Second, existing INTERFACE bocks are not themselves parameterized which would defeat the intention of enabling reuse. 3. There is no existing mechanism to imply that a _named_ INTERFACE block is "required" within a template. Existing mechanisms to reference a named INTERFACE block allow the use of the generic name. (Examples would be useful here, but time in insufficient.) Subroup is not strongly opposed to using some novel parameterized variation of "INTERFACE" as how one would spell "RESTRICTION". But we do not immediately see how to reuse anything remotely like existing syntax to provide the role of "REQUIRES". If something close to existing syntax can be repurposed in the generics context, that would be good. If anyone is interested in pursuing this, subgroup would be happy to assemble a handful of relevant use cases that should be addressed. | | L. A template may not use any procedures or operators except those | that have been specified in a REQUIRES statement. | | This restriction can be handled by PROCEDURE statements, and | non-overridable (but confirmable) IMPLICIT NONE(TYPE,EXTERNAL). This is syntax. If others agree that it is illegal to write a TEMPLATE that lacks IMPLICIT NONE(TYPE,EXTERNAL) than this might be workable. | Presumably, it does not apply to intrinsic procedures, or procedures | accessed from intrinsic modules. Prohibiting use association from | nonintrinsic modules might be a bit too strong. Subgroup agrees that the statement L is too strict, but have only addressed this in the specs paper. If it is crucial, subgroup will further amend the requirements paper to clarify. | See also item D above | about allowing modules to be template parameters. Not applicable, as those have been rejected. | | UTI-1: Can operator relations in a restriction specify rank? | | The "@" syntax for explicit shape declarations should handle | this. But that appears not to have been implemented yet. | | ===END===