-
Notifications
You must be signed in to change notification settings - Fork 461
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
Redo UPLC purity analysis to match PIR #5541
Conversation
@@ -1,9 +1,9 @@ | |||
(lam | |||
b_5 | |||
[ |
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 is the case that gets worse. I think this is pretty subtle and I'm not too sad that we don't see this.
(I think this is covered by the previous changelog entry) |
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.
I don't think the <>
short circuits once it hits the first Unknown
does it? It could build a much longer DList than needed, which then needs to be converted to a regular list in linear time, before it can be inspected.
There's a test in the PIR version that the whole thing is lazy enough: it successfully processes a term with an Which reminds me, I should port the tests over too. |
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.
Note that it also can't be creating the "spine" of the DList, since knowing what the spine looks like requires analyzing later terms, which we know it doesn't.
Yeah, you are right.
cf47cc0
to
ec13ada
Compare
This is the UPLC counterpart of the PIR work. Broadly small improvements.
The new logic almost entirely subsumes the old
delayAndVarIsPure
logic. There is one exception: we would effectively propagate the "forcing" context through several steps of evaluation, which is quite tricky, and the current code does not try to do. Now we only go into the body of a delay if it is immediately enclosed by a force. I don't think this is a huge loss, though.Also this finally fixes the broken testcase (it's still weird, but now it's just GHC's fault).
Pre-submit checklist: