Minutes

2023-17-03

Attendees

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

Case (1): Extreme limitations on use of deferred constants.

1. Deferred constants are not const-expressions
2. Deferred constants can be used as KIND, RANK, and LEN (as can const-expressions)
3. Cannot use inquiry function on entities with deferred characteristics in a specification expression
4. Possibly allow logical expression requirements for improved error messages.
   • New UTI: Logical expressions with deferred constants are not const expressions ...

Case (2a): Different const expressions (syntax) are different values inside template

1. Deferred constants are const expressions
2. Deferred expressions with different syntax are different values within template.
   • E.g., N+1 /= 1+N
3. 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)

Case (2b): Much, much harder on compiler, but friendlier to user

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?

Case (3): Strong concepts do not apply with deferred rank/kind

---

2023-07-03

Attendees

• 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:

1. 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.
2. Variant proposal from Ondrej is to treat different expressions as different values. So M+N is different than N+M when 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 1 - no meeting next week

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.

2023-06-26

• 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"