-
Notifications
You must be signed in to change notification settings - Fork 28
ENH: parse and expand bound tuples #140
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
Conversation
Signed-off-by: Markus Alexander Kuppe <[email protected]>
Signed-off-by: Markus Alexander Kuppe <[email protected]>
|
I will try to rebase the changes. |
|
Great! You can run the parser tests with tlapm/test/parser/parser_tests.ml Lines 92 to 97 in 56f33ef
If you delete those test names from the list then the test should pass if these changes fix all those cases. |
and update the code throughout `tlapm`, because this commit changes the existing types in the module `Expr.T`. Signed-off-by: Ioannis Filippidis <[email protected]>
The change in this commit corrects a bug with function definitions. Parsing of function definitions allowed using unbounded declarations (and also mixing bounded and unbounded declarations). For example, before this change, parsing allowed: ```tla f[x \in S, y] == TRUE ``` and even: ```tla f[x] == TRUE ``` These syntax errors are detected by SANY. In any case, this change ensures that `tlapm` does not parse such definitions. The error was due to calling the function `bounds` within the function `ophead`, instead of calling the function `boundeds` (which was called before commit 5958dfa in order to handle function constructors within the function `atomic_expr`). This commit also adds tests for this bug. Signed-off-by: Ioannis Filippidis <[email protected]>
because TLA+ does not allow this kind of syntax. A single rigid quantifier can include either: - only unbounded declarations, for example `\E x, y, z: ...`, or - only bounded declarations, for example `\A x \in A, y \in B, z \in C: ...`. A single rigid quantifier cannot include both bounded and unbounded declarations. This syntax is caught by SANY. Signed-off-by: Ioannis Filippidis <[email protected]>
in other words, that the following expression is not allowed: ```tla [x \in S, y |-> TRUE] ``` and the following expression is allowed: ```tla [x \in S, y \in S |-> TRUE] ``` Also, add a reminder in a comment in the parser code. Signed-off-by: Ioannis Filippidis <[email protected]>
instead of appending during the fold. This approach is more efficient. Also: - STY: blankspace formatting Signed-off-by: Ioannis Filippidis <[email protected]>
Signed-off-by: Ioannis Filippidis <[email protected]>
## ENH: tuply declarations
This commit adds parsing and translation support for
tuply declarations that appear in:
- rigid quantification `\E ... here ...: ` and `\A ... here ...: `
- choose expressions `CHOOSE ... here ...: `
- set constructors
`{... here ... \in ...: ...}`
- set constructors `{...: ... here ...}`
- function definitions `f[...here...] = ...`
- function constructors `[... here ... |-> ...]`
Commit 5958dfa introduced
parsing of tuple declarations in function constructors,
for example for expressions of the form:
```tla
[<<x, y>> \in A \X B |-> x + y]
```
This commit rewrites that functionality, and uses the
new functionality to parse tuple declarations that can
appear in function definitions, i.e., definitions of the form:
```tla
f[<<x, y>> \in A \X B] == x + y
```
The parsed tuply declarations are then transformed to either:
- optimized expressions that are simplified and do not
contain additional `CHOOSE` operators, in the presence of
a syntactically-recognizable Cartesian product of
suitable length, or
- the expressions defined by TLA+ semantics (in most cases
these expressions contain `CHOOSE`), otherwise.
This commit also adds tests for the above functionality.
## BUG: correctly represent tuple declarations in function constructors
In general, tuple declarations in function constructors
are defined using `CHOOSE` with tuple declarations,
which in turn is defined using unbounded `CHOOSE` and
quantification.
This was not how function constructors were implemented
in commit 5958dfa.
This commit corrects this error. The previous encoding
is closer to what is currently done when a Cartesian
product of the appropriate length is recognized in syntax.
## Tuplification
This commit adds a translation of function constructor
signatures that tuplifies comma-separated declarations,
and fuses the domain-bounds of such declarations into
a Cartesian product.
The motivation for doing so is that it enables passing
such functions (of tuples) to Isabelle and Zenon with
the existing support that is available in those backends
(for tuples and Cartesian products), and the proofs succeed.
## Other changes
- DOC: update file `todo.txt`
- ENH: add function `E_visit.name_operators` for
converting syntax trees with positional operator
references to syntax trees with operator
references by name (i.e., conversion of `Ix` nodes
to `Opaque` nodes).
Signed-off-by: Ioannis Filippidis <[email protected]>
Signed-off-by: Ioannis Filippidis <[email protected]>
Signed-off-by: Ioannis Filippidis <[email protected]>
a7e8d5e to
303e7f8
Compare
|
Thank you for noting how to configure the parser tests. Rebased (omitted blankspace and formatting changes) and updated to recent changes. The parsing tests pass, including also one more, about |
|
Okay great! Are you able to join the next TLA+ community call on November 12th and talk about these changes? They seem really great so I would like to get everybody talking about the best way to get them in. |
|
Yes, I can join the next TLA+ community call and talk about the changes. Thank you for suggesting it! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good but I have a few remarks and suggestions you might want to take into account.
|
Thank you for reviewing! I will work on revising the changes. |
<tlaplus#140> Signed-off-by: Ioannis Filippidis <[email protected]>
Signed-off-by: Ioannis Filippidis <[email protected]>
johnyf
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the remarks and suggestions, I revised the changes by adding 2 new commits.
damiendoligez
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. We can merge this after you remove E_namespaces or if you prefer to keep it.
|
Thank you for approving the changes. I removed |
Signed-off-by: Ioannis Filippidis <[email protected]>
319335b to
7af4592
Compare
|
Thank you for merging. |
Parsing and translation support for bound tuples, examples:
\E <<x, y>> \in A \X B: ...CHOOSE <<x, y>> \in A \X B: ...{<<x, y>> \in A \X B: ...}{...: <<x, y>> \in A \X B}f[<<x, y>> \in A \X B] = ...[<<x, y>> \in A \X B |-> ...]The syntax tree is changed to represent bound tuples. The translation is after the parser and before conversion to indexed identifiers. Subexpression references where bound tuples occur are not supported.
If a Cartesian product is found in the expression, of the same length as the bound tuple, for example
<<x, y>> \in A \X B, then a rewriting to a simpler expression is applied. For example,is translated to (the names of auto-generated identifiers differ):
Another case is:
which is translated to:
Otherwise the rewriting results in expressions that contain
CHOOSEor quantification.Includes fixes to parsing of declarations in function definitions and quantification.