-
Notifications
You must be signed in to change notification settings - Fork 479
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
UPLC case-of-case improvements #5966
Comments
The name of the transformation is self-explanatory: this is basically case-of-case transformation. The reason it is useful is because it can trigger case-of-known-constructor transformation on |
Yes, I think we already do that when compiling cases. Forces and delays are only added if at least one of the branches isn't pure. |
The name is self-explanatory, but the
In the UPLC case-of-case transformation? Where? |
I think it's in the compilation of |
Ah, I misunderstood, I thought you were saying it was already implemented for UPLC case-of-case. |
After #5960 we have some left-overs:
Plus, there's no explanation of what we do and why we do it.
the PR added generation of extra
force
-delay
pairs, why don't we see them in the existing golden tests? Those that were affected by the original PR introducing case-of-case? UPD: @ana-pantilie figured it out: it's because we know how case-of-case in PIR and so no suitable expression survives compilation of PIR to be transformed at the UPLC level. Thanks Ana!should we avoid generating
force
-delay
pairs when branches are pure?what about PIR, do we have the same issue there that was fixed for UPLC?
UPLC case-of-case is exponential in the same way as PIR case-of-case (see this and below).
The text was updated successfully, but these errors were encountered: