[J3] [EXTERNAL] Re: Paper 22-120r3 is now available

Tue Mar 8 01:06:48 UTC 2022

Van,

I’ll look more closely at your comments tomorrow (I hope), but one thing caught my eye:

Magne suggested that a generic binding might need to be "revised", for example because a sort procedure might want to use > instead of <.  That should be handled by the definition of the actual parameter. For Magne's example of + actually being min, or < actually being >, the definition of the actual parameter could do that by using a different specific procedure in the binding, e.g.

type :: FOO
  ! blah blah blah
contains
procedure :: Greater => Foo_greater
generic :: OPERATOR(<) => Greater
end type FOO

This does not work.   You want to change it at the point of INSTANTIATE.   How does the template know which actual TBP is to be mapped?

  *   Tom

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, March 7, 2022 at 5:20 PM
To: j3 <j3 at j3-fortran.org>
Cc: Van Snyder <van.snyder at sbcglobal.net>
Subject: [EXTERNAL] Re: [J3] Paper 22-120r3 is now available

On Mon, 2022-03-07 at 13:47 +0000, Clune, Thomas L. (GSFC-6101) via J3 wrote:

This version of the paper has a number of improvements based upon the discussion last week.    There is a longish section at the end that attempts to address the concerns subgroup has about allowing a more general declaration for template dummy type parameters.   The section contains 2 straw votes.

I do not think it is safe to assume that everyone will have time to read this version of the paper prior to our meeting today, so discussion and straw votes will need to wait until Wednesday.

Cheers,

· Tom

IN B, I would add that a restriction describes properties of dummy parameters as well as relationships between them.

I assume a RESTRICTION could be placed in a module, and accessed therefrom by USE association in the definition of a template, or accessed in a template by host association. Is there a compelling reason that the module from which it is accessed cannot be a template parameter?

In D and E, is there a compelling reason that a template parameter cannot be a variable? We allow procedures to have arguments that are variables; we do not require that procedures access variables that ought to be dummy arguments by using dummy procedures.

In E, INSTANTIATION should be INSTANTIATE.

In E5 Rationale, "too disallow" should be "to disallow".

Section F is problematic for processors. Instead of "same instance within a program", "same instance within a program unit" is probably easy to do. If a program wants to reuse an instantiation in several places, put it in a module and access the instance by use association. The NOTE also applies to SEQUENCE.

At the end of M, What does "REQUIRES statement unless those"  mean? Unfinished sentence?

Straw vote 1: yes.

Allowing type-bound procedures requires that PROCEDURE statements in the CONTAINS part of the TYPE definition either do not specify the name of  a specific procedure after =>, or it's ignored. The identifier of the bound procedure is taken from the actual parameter.  The identifier of the specific procedure is NOT taken from the type definition in the template by using the identifier before or after =>, as is the case for a type definition that is not a template dummy parameter. With this caveat, many of the objections in the discussion of Straw vote 1 become irrelevant.

Component and procedure declarations are minimum requirements, not exclusive requirements. Component declarations do not imply an order. Component order is determined by the actual parameter.

Most importantly, allowing component and type-bound procedure declarations does not requre the facility to be used in every template. The arguments against allowing them apply only in the case when they're actually used and then only in those cases when they cause problems. The problems are easily avoided, in those cases, by not using the feature. Why prohibit it everywhere?

During development of Fortran 90, I proposed that EXIT should apply to any labeled construct. The argument against it was "I wouldn't use it." Of course, the answer to that was "then don't use it. But don't prohibit me from enjoying its utility." It wasn't allowed until Fortran 2008.

With this description of type-bound procedures in dummy template type parameters, straw vote 2 becomes irrelevant.

I don't understand what problem might arise from allowing type parameters for template dummy type parameters. Declarations of variables of those types would specify values for the parameters using concrete values or template dummy parameters -- or specify them using asterisk or colon where allowed.

Under D add

Declaration of a template dummy parameter that is a type uses the same syntax as a type definition. (Yeah, this belongs in a specs or syntax paper.)

Component declarations impose minimum requirements on the actual parameter, not exclusive requirements, i.e., the actual parameter might have additional components. Component order is specified by the actual parameter, not by the order of component declaration in the declaration of the dummy parameter.

NOTE: Characteristics of components of dummy type parameters, other than their names and whether they are arrays, can be specified by template dummy parameters.

Type-bound procedure declarations impose minimum requirements on the actual parameter, not exclusive requirements, i.e., the actual parameter might have additional bindings. A PROCEDURE or GENERIC statement declares only a binding and the characteristics of the bound procedure, not the identifier of the specific procedure to which the binding applies. The specific procedure to which a binding applies is specified by the actual parameter.

Magne suggested that a generic binding might need to be "revised", for example because a sort procedure might want to use > instead of <.  That should be handled by the definition of the actual parameter. For Magne's example of + actually being min, or < actually being >, the definition of the actual parameter could do that by using a different specific procedure in the binding, e.g.

type :: FOO
  ! blah blah blah
contains
procedure :: Greater => Foo_greater
generic :: OPERATOR(<) => Greater
end type FOO

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20220308/1da6d873/attachment-0003.htm>