Open effectfully opened 6 months ago
Plus, there's no explanation of what we do and why we do it.
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 case (constr t)
and case (constr f)
.
should we avoid generating force-delay pairs when branches are pure?
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 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
case (constr t)
andcase (constr f)
.
The name is self-explanatory, but the force
-delay
caveat was so obscure that if went through the review process without anybody noticing. This must be documented.
Yes, I think we already do that when compiling cases.
In the UPLC case-of-case transformation? Where?
In the UPLC case-of-case transformation? Where?
I think it's in the compilation of Case
in GHC Core into PIR, but it's the same idea.
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).