[J3] [EXTERNAL] Re: Draft requirements paper

Tue Feb 8 20:09:12 UTC 2022

Hi Van,

Please see subgroup’s responses below (in bold green font)

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of j3 <j3 at mailman.j3-fortran.org>
Reply-To: j3 <j3 at mailman.j3-fortran.org>
Date: Monday, January 31, 2022 at 7:32 PM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: Van Snyder <van.snyder at sbcglobal.net>
Subject: [EXTERNAL] Re: [J3] Draft requirements paper

Comments on the generics requirements paper.

In general, I think most of the desired functionality can be expressed by existing sytnactic devices, with minor extension to their semantics when they are used to declare dummy parameters.

Dummy parameters that are required to be types can be declared using TYPE declarations. Rather than being empty, as in the examples, they can have component, type-bound procedure, and generic binding declarations. These would be minimum, not exclusive, requirements on the actual parameters. Data component declarations would require that the corresponding actual parameter have components with those characteristics, but not necessarily in the same order, and the actual parameter could have additional components. Similarly for type-bound procedures and generic bindings.

Subgroup did consider this.    We found that there were relatively few use cases where this is useful, and it reduces the elegance of templating to some degree.     We’re oppose to allowing data components on general principle, but do sympathize a bit with type-bound procedures.     Different types are likely to spell the same procedures differently and even used different OPERATORs for similar functionality.   The power of a template is therefore maximized by instead requiring a procedure to be passed as a template parameter.    There is no loss of generality, as a type-bound procedure can always be wrapped.  (And if it is not PRIVATE, can even be passed directly.)

Dummy parameters that are required to be procedures or interfaces can be declared using interface blocks. If a dummy parameter is an interface, its interface block might contain interface bodies that are not for dummy parameter procedures. Whether these procedures can be accessed by their specific names can be decided in due course (probabnly not). It would be reasonable to require that any non-intrinsic types for dummy arguments of procedures defined by  interface bodies for dummy procedure parameters must be dummy parameters that are types. This might, however, lead to very long parameter lists, so it might also be reasonable to allow types for dummy arguments to be accessed by use or host association. This would be another place that exposes that the Fortran 90 prohibition against host association into interface bodies was a mistake (about which I warned in 1986): One must include an IMPORT statement, else get inscrutable error messages (hopefully when the template definition is processed, not when it's instantiated). An argument might be made, in this context, for parameters that are modules, and to allow the types of arguments in these interface blocks to be gotten from a parameter module by use association.

In 2008, module procedure interfaces provide host association without requiring IMPORT.  In any event this is syntax, and therefore premature.   But even without that, we have accepted that IMPORT is just one of those annoying things like PRIVATE and IMPLICIT NONE that good coders have to put in certain places.

Dummy procedures that are required to be variables can be declared using tyoe declarations.

We (subgroup) could not parse that sentence.   If you meant “Dummy parameters”, then you are delving into SYNTAX, which is a bit premature.

Dummy procedures that are required to be constants can be declared using type declarations and an attribute similar to PARAMETER, but spelt differently, say CONSTANT, so as not to require an initialization expression in their declarations (or use PARAMETER with a caveat in the constraint that prohibits the initialization expression in the declaration of a dummy parameter).

Assuming again you meant “Dummy parameters”:    This is SYNTAX – we’re not opposed to the approach outlined here.

It would be useful to allow dummy parameters to be modules, templates, or template instances. The requirements for templates could be expressed by interface bodies whose interface blocks are template declarations. Of course, an interface block that is a template declaration would only be allowed for a template dummy argument. Only a constraint, not a new syntactic construct, is all that would be required. As with modules, circular dependency must be prohibited. "A template instance shall not instantiate itself, either directly or indirectly."  This might induce a requirement for syntax to list the public entities that such a module parameter must provide, so as not to delay error detection until instantiation.

Some consideration has been given to at least allowing a template argument to a template, but we found no use cases that warranted the extra complexity.  And Magne warns against the dangers of meta programming that appear in such contexts.   It would be a natural extension in a future revision if there is interest.   And subgroup won’t even grumble much if plenary pushes this into the requirements.

[47 Rationale 1] Ada does not need a construct different from "package" to define a generic package. If a package is generic, the word "generic" with a parameter list appears before the package declaration.

It is unfortunate that the Requirement paper implies something other than parameterized modules.    We needed a name with minimal implications.    It could be that the spelling of TEMPLATE is ultimately MODULE with parameters.  However, subgroup is currently more in favor of a new construct that can be defined and then used within the same program unit, which would not be the case for parameterized modules without further changes to what is meant by MODULE.   The upcoming SPECS paper will make this distinction more explicitly, so we can re-examine this aspect when that paper is available.

[50 Rationale 2] Ada allows generic packages to have public or private child units (private chilld units are what we call submodules). I used Ada for several years, including generic packages, but I never used a generic package that had child units. I can put anybody who is interested into contact with experts (mostly members of WG9).

Subgroup could not find a good way to do the analog of submodules, but only spent a short time discussing it.  I will follow up with a separate email requesting such a contact.   We do see some value if this can be allowed.   It might even sway us a a bit on parameterized modules vs a separate TEMPLATE construct.  (But doubtful.)

[54-67 Restrictions] As is the case for dummy arguments of procedures, restrictions can be expressed either by object declarations, type definitions or interface bodies for dummy parmameters. A different kind of block is not needed. See also [165-179] remarks below.

Subgroup strongly feels that _named_ requirements provide extra clarity and, most importantly, enable reuse.  We have found that this is a common pattern in  nested templates.    But we do agree that existing syntax could be made to serve the other aspects of constraining dummy template parameters aside from this.   Our intent is to reuse said syntax within a RESTRICTION.   Again, the SPECS paper provides more detail.

[78 Variable] should include named constant. Whether a data-object dummy parameter is required to be a constant can be specified by something like the PARAMETER attribute, but spelt differently, say CONSTANT, so as not to require an initializatione expression in its declaration or a caveat in a constraint. This would allow a dummy parameter to be used in constant expressions.

This is SYNTAX.  But not subgroup is not opposed.

[84 Value] should include variable, see [78] remark.

[111 E2] There does not appear to be any reason that a variable could not be an actual parameter to a template. As is the case for a type, procedure, or operator, in order to be an actual parameter, a variable would need to be accessible at the point of instantiation. This is more like argument association than host association. There might, however, still be stylistic reasons not to do this (some people have objections to host association), but why prohibit it altogether?

Subgroup is not opposed to such parameters, but none of the existing use cases drive such a requirement.    It would be an easy extension in some future standard.   We can see some scenarios where this might be helpful, but at the same time  we see straightforward methods to achieve the same functionality using a template variable and a template initialization procedure to capture the value or a pointer depending on the scenario.

[118 Notional syntax] An instance ought to have a name so that its guts can be accessed using essentially the same mechanism as use association, including ONLY and renaming. Otherwise, it's not much different from "include with parameters."

We think that the SPECS paper addresses this.   I suggest you wait for that paper, which should be done before the Feb meeting.

[137-142 Multiple instances] Multiple instances with identical actual parameters being identical entities is wrong headed. It puts an enormous burden on processors in the case that different instances are created in different scoping units. It demands a database that is far more complicated than ".mod" files.

We agree that this does create some burden on the implementors, but we thing that it provides significant benefit to users that are attempting to combine templates across multiple packages.   Otherwise one quickly gets frustrated when say a List of INTEGERs is incompatible between Package A and Package B even though they both used the same template from package C to define the List.   How is the end user supposed to fix this?  They have to get the developers of the other packages to agree that one of them will export the INTEGER List to the other?  But you might be the only user in the universe that combines these packages.   Containers are probably the worst case for this, but it seems likely that other scenarios will encounter this dilemma if we drop the requirement.

Also note, at least one vendor thinks this this requirement can be implemented, but we expect that vendors without a C++ compiler will have more difficulty.

[151 H] Typo: "An" should be "A".

Will correct.  Thanks.

[165-179 Restriction] A "Restriction" block probably isn't necessary. Restrictions can be described within a type definition for a dummy parameter using the usual syntax. E.g., a requirement for a component with particular attributes would be expressed by the usual component declaration. A requirement for a particular type-bound procedure, with a generic identifier, would be expressed in the usual way.... Restrictions defined external to templates can be provided by other templates, or by modules, e.g., a type definition or interface body accessed by use association. If a dummy parameter is a type, component, type-bound procedure, and generic binding declarations express minimum requirements, not exact requirements. For example, if a dummy parameter must be a type that has a scalar integer component, it can have other components as well. A "named restriction" could be used in a statement, instead of a block, similar to a declaration of a dummy procedure using a PROCEDURE statement. But this probably isn't necessary if, for example, the definition for the dummy parameter U in the example included type-bound procedures with type-bound generic identifiers. If one does not want to require that the necessary operators be provided by type-bound procedures, interface bodies ought to suffice to provide requirements. The example in requirement K suggests that OPERATOR(+) and OPERATOR(*) must simply be accessible at the point of instantiation. It would be better if this requirement could only be specified by declarations of dummy parameters: The TMPL2 template ought to have either type-bound operators for types U and V, or dummy parameter operators declared by interface bodies.

We do desire to reuse syntax, but we also desire to have the ability to reuse in other scopes and thus want to be able to give names to these restrictions.

[201-202 Strong concept] I assume that intrinsic procedures, and intrinsic operators with operands of intrinsic type, are allowed without being specified as requirements.

Yes.  Likewise one may have USE statements within a template that bring in other types and procedures that can be used within the template.   These would of course be independent of the actual template parameters.  This should be specified in the SPECS paper. (This may prove to be a bad practice though.)

[213 N] Typo: "is syntax" should be "as syntax".

Will correct. Thanks.

[219-222 Commentary] I assume this means that actual parameters are not allowed to be type-bound procedures, just as we do not allow actual procedure arguments to be type-bound procedures. Presumably, dummy parameter types are allowed to have type-bound procedures and generic bindings. Dummy parameters that are types are declared using non-empty type definitions, as described above, and thereby can be required to have certain type-bound procedures and generic bindings.

First, a correction to your statement.  Technically type-bound procedures are just procedures, and can definitely be used as actual procedure arguments.   Type-bound just gives a new mechanism for accessing them.  And it is true that the type-bound mechanism cannot be used as a dummy argument.    And it is often the case that such procedures are PRIVATE and are thus often not available in the required form to use as actual arguments and now actual parameters.
If someone wishes to use their type-bound procedure as an actual template parameter, they will be using it as a regular Fortran procedure.  If that procedure is inaccessible due to encapsulation in a module with PRIVATE, then the user will need to write a thin wrapper to use as the actual procedure.    This is not a perfect situation, but we found it to be a workable compromise for the existing use cases and sidesteps complexities arising from the different forms of access in the type-bound context.      We did not start there, but we have increasingly found that it is best to make minimal use of OO features in the generics context.   It maximizes the generality of a template.  Lots of guidance from Magne on this.

Cheers,

  *   Tom

On Mon, 2022-01-31 at 17:28 +0000, Clune, Thomas L. (GSFC-6101) via J3 wrote:
Just in case some interested parties are not actively monitoring the Generics subgroup in the forum:

I have uploaded a draft requirements paper for Generic features in the generics folder on J3.   I then started a discussion of said paper at:

https://j3-fortran.org/forum/viewtopic.php?p=514&sid=0c84afbe60d8c5c91b9c93abb0a0dad1#p514<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fj3-fortran.org%2Fforum%2Fviewtopic.php%3Fp%3D514%26sid%3D0c84afbe60d8c5c91b9c93abb0a0dad1%23p514&data=04%7C01%7Cthomas.l.clune%40nasa.gov%7Cdd882e63bc2a4b6c963508d9e51a4421%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637792723244171799%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=GVsrUgLdwk8coO74LK5dnmlxMlA7MFnqXZCJQzYxvDM%3D&reserved=0>

Subgroup is very interested in feedback of all sorts.   We lack depth in the standard, and are sure that things can be improved.

The plan is to bring this paper to vote at the Feb. meeting.     Specs paper is coming along and will hopefully be available for comments in 1-2 weeks.

Cheers,

· Tom

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