-
-
Notifications
You must be signed in to change notification settings - Fork 40
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 conversion of Quint nullary polymorphic operators #3044
Conversation
Although my fix is sufficient to get over the conversion phase and produce valid TLA+, I see now that it is not sufficient to make snowcat happy:
So more to investigate. This PR still unblocks things, so might be worth moving foward with it at this point. I'm not sure. |
Yeah, the behavior of |
I guess, this is the related issue: informalsystems/quint#1451 |
it is
Hmmm but Apalache doesn't need to infer the types, as we annotate everything. However, in the end, it complains that our annotation is too general. I'll need to further debug to understand if it is actually too general and Quint has to provide a more specific type, or if Apalache is expecting something too strict. Regarding the issue, I just confirmed that this PR fixed it. That spec works both with |
The most important question for me is whether there was a reason for not allowing something like |
I mean, the reason it's not allowed is simple, the basic notion of socpe-safety is that one name is only allowed to have one type in a given scope. For polymorphic operators, apalache/tlair/src/main/scala/at/forsyte/apalache/tla/typecomp/unsafe/UnsafeBaseBuilder.scala Lines 24 to 55 in afff436
() => Int or () => Bool ) it should give you what you want.
|
Right! If we expect the types to be correct, we can just use |
Ok, thanks for the input, it makes sense! Took me some time to figure out how to do it as I couldn't use |
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 great! Thanks for fixing it and going the extra mile in using UnsafeBuilder!
I will merge it right away to a cut a fresh release |
Hello
Here's another fix for the conversion from Quint. I was hitting problems whenever
None
was used to construct values of different types inside the same operator. Upon debugging, I realized this was specific to nullary operators (such asNone
), and that the builder itself enforces that the same name has the same type in a same scope. A concrete example:One solution could be to use a polymorphic type (a type variable) for constructing the
None
name in TLA+, but that is too general and causes issues later on. So, instead, I wrote a new builder methodpolymorphicName
that bypasses this check, and used that to construct names for nullary operators.This is only a problem currently for nullary operators, as regular operators go through the application translation (not the name expression translation) and are dealt with differently.
make fmt-fix
(or had formatting run automatically on all files edited)./unreleased/
for any new functionality