Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deep delta aggregates #81

Open
danhettena-nvidia opened this issue Sep 20, 2021 · 2 comments
Open

Deep delta aggregates #81

danhettena-nvidia opened this issue Sep 20, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@danhettena-nvidia
Copy link

Summary

Analogous to the TLA+ EXCEPT operator (see https://lamport.azurewebsites.net/tla/book-21-07-04.pdf, section 5.2), enhance Ada delta aggregates to support updates to components of components, components of components of components, etc.

The following example demonstrates the capability, but not necessarily the best language design choice for the syntax.

This hypothetical syntax (which, again, is not necessarily the best syntax; that should be debated):

base_expression with delta '(' choice_expression1 ')' '.' component_selector_name1 '(' choice_expression2 ')' '.' component_selector_name2 => expression

Would be equivalent to this:

base_expression with delta choice_expression1 => base_expression '(' choice_expression1 ')' with delta component_selector_name1 => base_expression (' choice_expression1 ')' '.' component_selector_name1 with delta choice_expression2 => base_expression (' choice_expression1 ')' '.' component_selector_name1 '(' choice_expression2 ')' **with delta component_selector_name2 => expression

Motivation

When using SPARK to specify procedures that modify just one state variable inside a nested data structure such as shown above, one delta aggregate expression is substantially easier to comprehend than a sequence of delta expressions.

Caveats and alternatives

(1) The syntax would need to be debated. In particular, my suggestion above to use parentheses to wrap choice expressions is suspect.

(2) I have not thought through whether all current features of delta aggregates fit neatly with the proposed feature. For example, I am unclear on whether a component_choice_list with multiple component_selector_names should be supported in combination with the proposed feature.

@danhettena-nvidia danhettena-nvidia added the enhancement New feature or request label Sep 20, 2021
@sttaft
Copy link
Contributor

sttaft commented Sep 20, 2021

This could have the advantage of helping to unify record and array delta aggregates, and include support for multi-dimensional arrays, which were omitted from the first version of array delta aggregates. The BNF for this could become:

delta_aggregate ::= (base_expression with delta delta_subcomponent_association_list)

delta_subcomponent_association_list ::= delta_subcomponent_association {, delta_subcomponent_association}

delta_subcomponent_association ::=
    delta_subcomponent_choice_list => expression
  | discrete_choice_list => expression
  | iterated_component_association

delta_subcomponent_choice_list ::= delta_subcomponent_choice {'|' delta_subcomponent_choice}

delta_subcomponent_choice ::=
   (expression {, expression})
  | component_selector_name
  | delta_subcomponent_choice (expression {, expression)
  | delta_subcomponent_choice . component_selector_name

The discrete_choice_list and iterated_component_association would only be usable for single-dimension arrays. The more general delta_subcomponent_choice-based syntax could be used for both arrays and records.

@yannickmoy
Copy link
Contributor

@sttaft I guess you'll want to preserve the syntax with square brackets [..] for array delta aggregates, as this is currently allowed by the syntax of Ada 2022: http://www.ada-auth.org/standards/2xrm/html/RM-4-3-4.html

I agree that the syntax that you propose looks natural, and seems to solve the issue that was bothering @danhettena-nvidia

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants