Skip to content

Minutes

Jump to bottom
Tom Clune edited this page Jul 31, 2023 · 31 revisions

2023-07-31 Finally back to bounds and keywords for deferred arguments

Attendees

  • Tom
  • Brad
  • Magne
  • Mark
  • Lorri
  1. 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.
  2. 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.

2023-07-24 Mostly values of deferred constants again

Attendees

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

2023-07-18 Special meeting with Hideto

Attendees

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

2023-07-17

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

Partial workarounds for users are to have multiple deferred constants. E.g., if N+1 is needed, introduce NP1 deferred constant and use that.

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-03-07

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"
Clone this wiki locally