-
Notifications
You must be signed in to change notification settings - Fork 563
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
Trigger TCO even when there are some self references in non-tail positions #3968
base: master
Are you sure you want to change the base?
Conversation
Unfortunately it's very easy to introduce bugs when working on this code, so I think we need to be really careful about this (searching through this repo's issue history for TCO should provide a bit more context). It's unfortunately quite possible that our tests don't cover as many cases here as they should, so the fact that the tests are passing is not enough for me to be confident. The tests in this PR only check that the program finishes; they don't check the results of the TCO-transformed functions, which I think is also needed. For me, this would need a much more developed justification of why it works and would not break existing programs before we can consider it. In any case I think this needs to wait until 0.14.0 has been released. |
I agree with this. |
I couldn't find any semantics testing suite. Do we have such a thing? If so, I can write some tests to make it more clear that this approach doesn't break anything. |
I’m not sure what you mean by “semantics testing suite.” More tests might help but they aren’t really a substitute for an explanation of your reasoning and approach. |
(Attempting to move discussion of the proposal, as distinct from this implementation, to #3967.) |
My approach is just to alter the conditions for the TCO to trigger while leaving the present loopifier unchanged. Indeed, the only thing I changed was replacing "allInTailPosition" with "anyInTailPosition". The algorithm for resolving the tail calls remains as it was before – so if it was working back then, then should it work now as well. The only issue I can think of is that it may be a bit too much of artificial loops, but this discussion is continued in #3967 By "semantics teseting suite" I meant some already defined way of validating if the generated code evaluates in a desired way. I suspect I could do it by throwing errors on failing assertions in the |
They're in the minority, but a number of tests do use the functions from purescript-assert; you can grep for |
More occasional TCO any/all fix Self-reference in CONTRIBUTORS
fdd9558
to
0a79a59
Compare
Fixes #3967
Tests are passing on my side.