[J3] Draft requirements paper

Tue Feb 1 00:31:49 UTC 2022

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.

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.

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

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).

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.

[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.

[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).

[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.

[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.

[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?

[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."

[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.

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

[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.

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

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

[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.

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
>  
> 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/20220131/4c3c59c2/attachment-0001.htm>