-
Notifications
You must be signed in to change notification settings - Fork 47
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
Fix logical variable shadowing program variables #626
base: main
Are you sure you want to change the base?
Conversation
The implemented solution has been discussed at length in #122. Let's try not to put a new coin in the machine. |
I think you might have missed a case. In
do you instead want
Also, I find your description "This commit adds a new memory specifier that changes the resolution order: program variables firs & then logical variables." confusing. It seems that when there is a conflict about whether z, say, is a program variable or a logical variable in a pre or postcondition, that the answer is logical unless the {!hr}/{!1}/{!2} annotation is used to say it should be the program variable. |
Ah, and in pRHL pre- and postconditions, I guess I don't understand why you aren't still using {1} and {2}. In
do you want the user to run
still or
Some of the ambiguity is only there in Hoare or pHL, right, because in pRHL program variables are always decorated with sides in pre- and postconditions. The problem was one couldn't write z{&hr} in a Hoare pre- or post-condition. |
No. As discussed in #122,
Because we already have a lot of technical debts that I am pruning and I don't want to add extra exceptions to the code (i.e. have a behaviour that depends on the memory name)
You can use
But if In #122, we discussed two solutions: the one implemented here & the one where
What is a bug is that the pretty-printer is using the Let's remember here that we are fixing an ambiguity issue that happens when one has the (IMO bad) idea to use the same name for a program variable & a logical variable. |
Also, EasyCrypt used to print a warning message when a memory annotation was not used by the typer. This seems to fail in the pre/post. Should also be fixed. In your first example, you should get a warning telling you that |
OK, thanks, I was misunderstanding things. "What is a bug is that the pretty-printer is using the {!_} too often. When there is no ambiguity, the pretty-printer should simply print the raw variable name, as before." So are you going to fix this before merging? |
Pushed. You first example now gives the warning |
Currently, when resolving an identifier, EasyCrypt tries to resolve it as a logical variable first, and then as a program variable (in the active memory), even when a memory specifier is given. This commit adds a new memory specifier that changes the resolution order: when using it, we first try to resolve the identifier as a program variable (in the given memory), and then as a logical variable if no program variable matching that name is found. The syntax if `form{!memory}`. The pretty-printer has been updated accordingly.
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 to me.
Currently, when resolving an identifier, EasyCrypt tries to resolve it as a logical variable first, and then as a program variable (in the active memory), even when a memory specifier is given.
This commit adds a new memory specifier that changes the resolution order: when using it, we first try to resolve the identifier as a program variable (in the given memory), and then as a logical variable if no program variable matching that name is found.
The syntax is
form{!memory}
.The pretty-printer has been updated accordingly.
Fix #122, fix #196