You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
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.
The text was updated successfully, but these errors were encountered:
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:
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.
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.
The text was updated successfully, but these errors were encountered: