-
Notifications
You must be signed in to change notification settings - Fork 8
Minutes CY2023
- Tom
- Brad
- Jon
- Magne
- Aury
- Eric Schweitz
- Mark
- We continued to kick around ideas about how to allow template procedures to be defined "elsewhere" Still lots of problems but a straw poll indicated that everyone still wants to pursue a solution in that direction.
- Separate discussion on simplified instantiations. Here there was some general agreement that things could be made to work.
- The largest struggle was over whether simplified template subroutines and template functions would have a separate name. Such a name would enable backward-compatible migration to more complex templates. (Brad)
- Strong desire to introduce additional characters to separate template parameters from argument list. Options include curly braces and even 2 character combos like "(<" and ">)" (which technically would not be new characters at that point.) Straw vote material for plenary surely.
- Tom
- Brad
- Lorri
- Jon
- Magne
- Mark
- Aury
Lots of discussion on how to deal with complex nested templates. Main focus was on allowing "nested" templates which would reside in the some module but would not syntactically appears inside their host template. syntax like template(host_tmpl) subtmpl(<params>).
Other discussion was on allowing inner template procedures to appear in the CONTAINS section of the host template. Either or both could be pursued.
We concluded with a brief discussion about syntax for simplified instantiation of procedures. At one extreme we would only support cases where the template parameters can be inferred from the procedure arguments. This would generally require procedures to be passed as dummy arguments rather than as template parameters and would not support cases where additional intermediate types are needed but not exposed in the procedure interface. More complex cases would required extra syntax and would beg for new characters "{}" to be used. (Which then begs the consistency with other template work.)
- Tom
- Brad
- Lorri (briefly)
Brad and I re-examined options for dealing with long templates. Here are the 4 alternatives considered:
- templates go in CONTAINS section of host scope (mentioned at last meeting)
- template procedures as analogs to (sub) module procedures.
- Limitation is that it can only "escape" one level of hosting.
- subtemplate analog of submodule
- simple case in same hosting scope does not provide much bang.
- extending to be in entirely separate scope seems to be fundamentally flawed. Either defers some compilation to link stage or requires overly strict order of compilation.
- include files - not as bad as you might think
- Brad will draft a paper summarizing
- Tom
- Brad
- Magne
- Lorri
- Jon
- ?? I think there may have been another. Apologies.
We made some progress on updating the full syntax paper based upon smaller papers from meeting 230.
- Tom
- Brad
- Magne
- Lorri
- Jon
-
Discussed again just what constraints we might want on generic names exported from templates. No consensus yet exists. Options:
- do nothing (error at instantiation)
- complicated constraint that disallows problematic cases
- simple constraint that disallows wider swatch of cases
- disallow generic names entirely, and let users deal with managing generic names outside of template
-
Long/nested templates Some plausible use cases with current syntax are ugly in that inner templates are "in-the-middle" of the outer templates leading do non-Fortranic file structure. Considered remedies:
- simple include statement
- preprocessor include statement
- "subtemplates" (appear to be circular at best)
- allow template declarations in CONTAINS section. This seems to help more than one might think at first glance. Some consensus appeared to be forming around this option.
-
We agreed that Tom would clean up the syntax paper intro slightly and upload to meet the 2 week rule.
2023-09-25 Updated syntax paper for polymorphic deferred entities and constraints on use of deferred constants
- Tom
- Brad
- Mark
- Lorri
- Magne
We suspect more work is needed for deferred constants.
There was also some discussion about amending our position paper on exporting intrinsic operators to include restrictions one exporting generics.
- Tom
- Brad
- Lorri
- Mark
- Magne
- Damian
We identified that there is really only one problematic case. If a template exports an intrinsic operator that has a specific procedure with all arguments either of deferred type or intrinsic type, then instantiations with intrinsic types will collide with intrinsic operators. We are not aware of any well-motivated use case that would expose this issue, but ... users are clever.
There is no issue here about what is legal vs illegal, but rather whether we want to catch the potential problem when compiling the template or accept a later more obscure error on the instantiate statement. We have tentatively decided to add a constraint to catch this within the template - again with the philosophy of maximizing backward compatibility going forward.
Actions:
- Brad will write short summary paper on discussions of kind & rank constants, and bounds & keyword
- Tom will write short summary papers on: deferred polymorphic types, logical requirements, and exporting intrinsic operators
- Tom
- Brad
- Lorri
- Magne
- Damian
Magne observed that most use cases for logical requirements do not really help the compiler to make a better error message. Or rather, a compiler can already make a good error message just by processing the code. This bumps the priority down. We agreed to defer logical requirements for now.
Some discussion also ventured into intrinsic requirements, but we agreed to defer these for now.
We then segued into support for deferred types with components and PDT's. Some ideas put forward, but I reminded everyone that we had already agreed to defer this feature until the subsequent standard.
Finally we circled back to the use of CLASS, DEFERRED :: T for polymorphic templates. Tom agreed to at least sketch a bit further for polymorphic keys and values for map/dictionary container for next meeting.
Next meeting is not until: September 11.
- Tom
- Damian
- Magne
- Mark
- Lorri
- Arjen
We discussed 3 approaches to enabling use of CLASS(T) in templates.
- New syntax
CLASS, DEFERRED :: T - New intrinsic requirement:
REQUIRE IS_EXTENSIBLE(T) - Code transformation with polymorphic designation coming from the INSTANTIATE statement:
INSTANTIATE tmpl(..., CLASS(T), ...)
Option 3 is the most powerful as it can allow a single template to work for both polymorphic and non polymorphic cases. But has several drawbacks: - Hard for the vendors (at least one on record stating "We wouldn't do that.") - Somewhat confusing to developers and users - interfaces "lie" - Likely that there would be certain situations where the appropriate transformation is not well defined. E.g., if the user intends an array of base type, the automatic code transformation would create an array of wrapped allocatable items.
The decision between (1) and (2) somewhat depends on how many intrinsic requirements are going to be introduced. If none, then (1) is clearly preferable. If multiple, then maybe (2) is desirable.
This led to a sizable discussion about related intrinsic requirements, and in particular something like
REQUIRES NON_AMBIGUOUS_OVERLOAD(T, U)
The intent would be for this to be used when a template defines a generic name that is ambiguous when 2 deferred types are the same. Using it would nominally enable the vendor to provide a clear error message when someone tries:
INSTANTIATE tmpl(integer, integer)
Action items:
- Tom will prepare a relatively complete implementation of a container that uses 2 templates. The 1st is non polymorphic and the 2nd is polymorphic but leverages the 1st. The idea/hope is to hand to Ondrej to explore issues.
- Tom
- Brad
- Magne
- Mark
- Lorri
- We had consensus to pursue option (2a) with regard to deferred expressions
- 2 deferred expressions have the same value only if they are identical expressions
- Deferred expressions can only be used in limited cases (not everywhere a const expression can be used)
- Possibly do not need a constraint on inquiry function of deferred entities aside from stating that these are deferred expressions themselves.
- We did real work on the BNF for consistency among ultimate specifications for deferred arguments. New section 3.1.3 is in place in the updated syntax paper on this site.
- Tom
- Brad
- Magne
- Mark
Did not reach consensus on how to handle deferred constants in context of strong concepts. Useful discussion and more examples. Still a spread of opinions on case 1 vs case 2a vs case 2b ...
Updated schedule ...
Fortran example file will be sent out in email.
- Tom
- Brad
- Hideto
Hideto provided slides that show his proposed approach for simple overloading of procedures. Brad demonstrated analogous examples using current (and some half-baked) syntax for templates.
(In my opinion) The existing examples do not show benefit for having multiple approaches here. More complicated/realistic examples should be explored to see if there are differentiating details.
Both approaches have some challenges in terms of how the multiple kind/types are to be expressed. In Hideto's case, we suspect they are solvable, but may not be quite as succinct as his current proposal. (PDTs with multiple kind parameters break the existing syntax we think.)
- Tom
- Brad
- Magne
Useful discussion about our options for dealing with strong concepts as it relates to the values of deferred constants.
We came up with the 4 positions below to debate/decide at the next meeting. I am advocating for option (1) which is safer and backward compatible with (2a) and (2b). Option (3) is just to round out the spectrum.
- Deferred constants are not const-expressions
- Deferred constants can be used as KIND, RANK, and LEN (as can const-expressions)
- Cannot use inquiry function on entities with deferred characteristics in a specification expression
- Possibly allow logical expression requirements for improved error messages.
- New UTI: Logical expressions with deferred constants are not const expressions ...
Partial workarounds for users are to have multiple deferred constants. E.g., if N+1 is needed, introduce NP1 deferred constant and use that.
- Deferred constants are const expressions
- Deferred expressions with different syntax are different values within template.
- E.g., N+1 /= 1+N
- Can use inquiry functions on deferred entities in specification expressions.
real, rank(N) :: x
real, rank(M) :: y
real, rank(rank(x)+rank(y)) :: z ! not M+N
real, rank(rank(y)+rank(x)) :: t ! not N+M (nor M+N)
real :: x(N)
real, rank(size(x)) :: y ! not rank(N)1. Deferred constants _are_ const expressions
2. Deferred expressions with different syntax are different values within template
- Simple substitution is not "different"
real, rank(N) :: x
real, rank(M) :: y
real, rank(rank(x)+rank(y)) :: z ! is M+N
real, rank(rank(y)+rank(x)) :: t ! is N+M, not M+N
real, rank(rank(z)) :: u ! is M+N
real :: x(N)
real, rank(size(x)) :: y! rank N?- Tom
- Brad
- Ondrej
- Magne
- Arjen
Primary discussion was concerning how/when to distinguish deferred constants with regard to interface checking for strong concepts. Two primary proposals were:
- Disallow expressions involving deferred constant. Use additional deferred constants when necessary. This is the safer option, but has some annoying consequences. Likely we would augment with "logical requirements" that express additional constraints among related deferred constants.
- Variant proposal from Ondrej is to treat different expressions as different values. So
M+Nis different thanN+Mwhen N and M are deferred. We were a bit concerned that this would not completely circumvent the quagmire, and at least one of us (Tom) is concerned that it will be strongly rejected at plenary (read Malcolm) as compilers ought to be allowed to see that two equivalent expressions are equivalent. We might break existing parsers for example.
We briefly discussed "simplified templates" (new syntax fro single procedure use cases). After a bit of 'splaining to Tom, we found we were all on the same page.
Note 2 - 2 meetings the week following. The usual Monday telecon and a special Tuesday evening telecon with Hideto to discuss succinct instantiations of a template with multiple argument lists.
-
Initial schedule/prioritization of work items
-
Discussed new refinement to the "lower bounds problem"
-
Stumbled upon frustrating aspects of strong concepts involving expressions of deferred constants. Exposes limits on what compilers can really check when compiling templates. (Strong concept crisis.)
-
Action items:
- Tom: schedule telecon with Hideto (simplified templates)
- Tom: post schedule to GitHub
- Tom: Update Magne on "strong concepts crisis"